For the community, there is always Keycloak 😉

I tried setting up several providers with the ring OAuth middleware, and it works fine for most of them. But I need “Log in with Apple”, and OF COURSE they don’t stick to the standards….

Yeah. Passport.js in Node land is trying to fill this gap, I'm not sure if there's anything like that in JVM or Clojure land.

For my application, I patched Ring OAuth to support Apple, too, but maintaining such a library to support several vendors, even those violating standards, sounds like a huge pain

That's where many hands usually helps. Not that it's a panacea of course.

So you are thinking about a library containing OAuth endpoints, authentication flows (maybe scopes) for the main social connectors? I’d be tempted… Keycloak is an alternative, but I really don’t want to set up and maintain additional infrastructure for this

Yeah the infrastructure is what turns me off Keycloak.

I was thinking this: http://www.passportjs.org but for Ring 🙂

Looks nice, I agree something like this would be very helpful as a Ring Middleware

https://github.com/magnetcoop/buddy-auth.jwt-oidc

We use it with AWS Cognito and Keycloack.

For Ring there is also https://github.com/weavejester/ring-oauth2, but none of them bring along specifics for the oidc providers, like passport would do

I mentioned password.js to a colleague that has used node more. But he says it's poorly maintained..

Yeah, the open issues / open PR don’t look to good, and there was no noteworthy activity for over a year now.

Seems it should still be Keycloak for us, luckily another team is managing that. (We are about to start with a new team)

<wizard> re-write it into Clojure and you’ll run it after 10 years </wizard> 😄

A proper way nowadays would be to use pyenv (preferably, with an addition of a virtual environment on top). With it, it's a breeze.

And just in case - never, ever, ever, run sudo pip. You will be in for some baaad time later on, guaranteed.

(assuming you're on *nix)

I sudo piped my way into making scripts work more times than I am willing to admit, unfortunately 😞

Embrace pyenv, my friend. :) At this point, this tool is a must for Python development.

Yeah, I actually used pipenv successfully a couple of times, but the whole zoo of pyenv/pipenv/virtualenv/venv/pyvenv, along with py2/py3 incompatibility, and compatibility-breaking library version updates, and strange version locking — really confuses me a lot.

It all boils down to "don't touch it if it works" strategy when I am dealing with Python

pipenv is a completely different tool though. I'm using it as well in one project, but in retrospective I think I would be better off without it, for various reasons. pyenv is the tool to manage different Python versions at user level. pipenv is one of many tools to manage virtual environments and dependencies for particular projects - there are many alternatives for that.

> compatibility-breaking library version updates, and strange version locking The whole Python community is largely a mess here, yeah. One of the reasons I now try to avoid dealing with Python at all.

I have given up and now only run python in docker containers.

I wouldn't choose YAML myself but it's clearly popular out there

sigh… yes it is. personally, I don’t find it much nicer than JSON

and I presume any kind of versioning or schema would have to be bolted on

if you want versioning and schema's xml is an option

its not the most ergonomic option

yes, excellent point. somehow had forgotten about XML

but some editors have good support for schemas

or perhaps just blocked it out of my memory

offering autocomplete and validation in the editor

how big is you're application config that you are running into problems?

well, we might have a notion of a “DB connection”, which has username and password keys to start. not too bad (ignoring, for a second, the problem of storing passwords in plaintext)

but then various other things can enter into the picture. like if using an SSH tunnel/bastion server to connect, the address and details of that server

and possibly SSH key blobs (which can be large binary objects)

and Java keystore file contents (also large binary objects)

so, maybe “application configuration” isn’t really the right way to describe this after all

“metadata managed by the application on behalf of the users”

ok so more like application state, i'd just store this in a database

yeah, that’s what we’re already doing

not normalized, though, in the form of JSON blob in a TEXT column

which is what I’m thinking about moving away from

if the format is somewhat stable i'd just create some tables for this

if it changes all the time maybe something like avro helps

avro has a good backward compatibility story for versioning

yep, that is true

I’m more used to thinking about Avro as being a data format, like in the Hadoop world

but it doesn’t necessarily have to be

given our deployment model though, the bytes would still have to be stored in the DB, which is kind of gnarly

yeah deployment always makes things complicated

I try to stick to simple environment variables for simple things (db urls, user, pass etc) that change between deployments, and chuck the rest in a database. If the configuration is supposed to be done in a file then a nice file format and a good example can be useful.

yeah that’s what I would prefer to do, too. unfortunately, in this case there is dynamic state being updated by users (administrative functions in the UI)