Clojurians Log v2

https://www.cnbc.com/2021/03/03/okta-is-buying-security-rival-auth0-for-6point5-billion-stock-falls.html

So, I was planning to integrate Auth0. Most people talking about Okta Support and Sales are not happy… are there any alternatives left out there you can recommend?

@javahippie join forces and let's develop something in the community... half joking but if the timelines align it would be nice.

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.

<rant> Oh the hoops I have to jump through, in order to run a python 2.7 script with all its dependencies on an up-to-date OS. I just want to run a script some other guy wrote three years ago, let me just run it! </rant>

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 🙂

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

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.

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)

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

Anyone have formats they particularly like for storing application configuration? These are parameter values for knobs we provide in the application, but which the users can set their own values for (and in some cases, can define their own “keys” as well). We’re quickly outgrowing the “big ball of JSON” and starting to consider alternatives to move to. The schemas will be fairly rapidly evolving, so easy versioning/migration is a must. I just saw something about DFDL, which looks interesting. Of course, since the backend is in Clojure, EDN has to be considered. Or something like Thrift perhaps. For purposes of adoption/expediency, it should ideally be something that can be serialized to a column in a relation DB fairly easily (ex: a BLOB/CLOB), or possibly stored in a set of normalized tables instead (is that a thing?). Anyway, all suggestions are welcome.

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