This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # asami (38)
- # babashka (20)
- # beginners (188)
- # cider (1)
- # clara (11)
- # clj-kondo (103)
- # cljs-dev (15)
- # cljtogether (1)
- # clojure (138)
- # clojure-australia (5)
- # clojure-europe (33)
- # clojure-france (1)
- # clojure-losangeles (5)
- # clojure-nl (4)
- # clojure-norway (11)
- # clojure-serbia (3)
- # clojure-uk (11)
- # clojurescript (45)
- # community-development (3)
- # conjure (22)
- # core-async (18)
- # datomic (44)
- # defnpodcast (4)
- # deps-new (1)
- # depstar (49)
- # events (2)
- # fulcro (33)
- # girouette (2)
- # honeysql (37)
- # jackdaw (5)
- # jobs-discuss (16)
- # kaocha (3)
- # leiningen (4)
- # lsp (77)
- # malli (55)
- # membrane (4)
- # off-topic (61)
- # polylith (5)
- # quil (5)
- # reagent (33)
- # reitit (12)
- # remote-jobs (1)
- # reveal (4)
- # rewrite-clj (2)
- # sci (16)
- # shadow-cljs (22)
- # sql (1)
- # test-check (27)
- # tools-deps (44)
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
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
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
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)
<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>
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.
sudo piped my way into making scripts work more times than I am willing to admit, unfortunately 😞
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.
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
yes, excellent point. somehow had forgotten about XML
or perhaps just blocked it out of my memory
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”
yeah, that’s what we’re already doing
not normalized, though, in the form of JSON blob in a
which is what I’m thinking about moving away from
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
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)