Fork me on GitHub
#off-topic
<
2021-03-04
>
javahippie07:03:14

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?

orestis09:03:16

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

javahippie09:03:00

For the community, there is always Keycloak 😉

javahippie09:03:45

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….

orestis09:03:15

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.

javahippie09:03:31

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

orestis09:03:50

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

javahippie10:03:49

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

orestis10:03:30

Yeah the infrastructure is what turns me off Keycloak.

orestis10:03:58

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

javahippie11:03:43

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

Asier12:03:33

We use it with AWS Cognito and Keycloack.

javahippie12:03:47

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

gklijs14:03:30

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

javahippie14:03:14

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

gklijs16:03:01

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

Timur Latypoff09:03:25

<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>

agigao10:03:33

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

p-himik15:03:26

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.

p-himik15:03:08

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

p-himik15:03:33

(assuming you're on *nix)

Timur Latypoff11:03:00

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

p-himik11:03:01

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

Timur Latypoff11:03:25

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.

Timur Latypoff11:03:31

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

p-himik11:03:02

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.

👍 3
p-himik11:03:09

> 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.

emilaasa18:03:06

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

Jeff Evans18:03:21

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.

noisesmith20:03:17

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

Jeff Evans20:03:43

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

Jeff Evans20:03:10

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

chrisblom20:03:07

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

chrisblom20:03:28

its not the most ergonomic option

Jeff Evans20:03:47

yes, excellent point. somehow had forgotten about XML

chrisblom20:03:53

but some editors have good support for schemas

Jeff Evans20:03:11

or perhaps just blocked it out of my memory

chrisblom20:03:14

offering autocomplete and validation in the editor

chrisblom20:03:56

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

Jeff Evans20:03:32

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)

Jeff Evans20:03:01

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

Jeff Evans20:03:12

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

Jeff Evans20:03:24

and Java keystore file contents (also large binary objects)

Jeff Evans20:03:45

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

Jeff Evans20:03:59

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

chrisblom21:03:13

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

Jeff Evans21:03:27

yeah, that’s what we’re already doing

Jeff Evans21:03:18

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

Jeff Evans21:03:25

which is what I’m thinking about moving away from

chrisblom21:03:23

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

chrisblom21:03:58

if it changes all the time maybe something like avro helps

chrisblom21:03:24

avro has a good backward compatibility story for versioning

Jeff Evans21:03:34

yep, that is true

Jeff Evans21:03:48

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

Jeff Evans21:03:57

but it doesn’t necessarily have to be

Jeff Evans21:03:10

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

chrisblom21:03:26

yeah deployment always makes things complicated

emilaasa18:03:51

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.

Jeff Evans18:03:59

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)