That might not be the best answer as I don't use uberjars, but my immediate thought would be to embed the version string in some .clj file during the build process instead of reading it from pom.xml at run time.

> embed the version string in some .clj Then I can make a version.txt, but I don’t feel a like any of this method

Why you don’t use uberjars?

Have had hard time solving some uberjar-specific issues years ago, decided to keep deploying just the source code and start apps with clj until I stumble upon any issue with such an approach.

(defn app-version []
  (some->> ( "META-INF/maven/data-collector/core/pom.properties")
          (slurp)
          (re-find #"version=(.+)")
          (last)))

If there is a maintained Java library that does all that, I'd guess that everybody just uses it via interop instead of searching for or building a Clojure solution or wrapper for that library.

yeah I always back to this topic from time to time and I still feel I didn’t find the right one library. Any recommendations?

Sorry, not from me. But maybe someone else knows.

Just my 2c: An OAuth2 client library is just an http client really - and a lot of services that claim to implement OAuth2 do this very differently (e.g. refresh token endpoint is on a completely different domain than the initial authorization flow, just to bring one up I've been dealing with recently). We've been moving off Ruby's Omniauth to Clojure only to realize that each service (8 out of 15 or so) we integrate with requires custom code for OAuth to some degree. Also, since you're dealing with refresh tokens - you have to account for storing them somewhere securely, that's way out of scope of a client, imho

Yeah, to echo what Lukas said: we wrote our own OAuth2 server and so we also wrote a client for it (the mechanics are straightforward -- http client calls, based on the OAuth2 flow) and then we integrated Facebook's OAuth2 as an alternative and the client flow for that was different enough that we wrote yet another "client" using HTTP calls, and we use several external services that also have OAuth2-based flows and... they're all a little different. I think that's why there's no single "OAuth2 client" library that is also well-maintained: the flows for each backend service are different enough that it's hard to make something generic and robust that's going to work with a bunch of services you've never seen 🙂

This is why in the JS world you'll find service-specific client libs that encapsulate details about that service's endpoints and flows. (at least, as I recall, from the last time I stepped into that space... which was a while ago)

this can explain why I always feel confuse why trying to do oauth2 things :)

It also depends whether you're doing server-to-server or integrating user-to-server into your web app 🙂

right now server->server, but I would like to have a lib which I would always use instead of each time trying to solve this problem from the beginning.

but your comments suggest it is only one way

This isn’t so much a fault of oauth2 as poor implementations not following the spec. The “refresh token endpoint” mentioned above is certainly not oauth2

@U03AU2X8TD5 Can you elaborate on that? My understanding of the spec, at least for a flow that involves a user and a browser, is: • app POSTs to auth server authorization endpoint with client ID and redirect URL etc • auth server responds with a redirect to a login server, where the user logs in • login server responds with a redirect back to the app (via the redirect URL) with a code • app POSTs that code to auth server token endpoint asking for an access/refresh token pair • app uses access token to verify user is allowed to access services (that part is a bit vague and allows for a range of server-to-server behavior as I recall) • app periodically POSTs refresh token to auth server token endpoint asking for a new access/refresh token pair • rinse and repeat last two steps

yes, that is pretty much the interactive flows as described by the spec 👍 with later, “add-on” specifications like the https://www.rfc-editor.org/rfc/rfc8414 one adopted pretty much verbatim from OIDC, implementations should need very little knowledge about things like endpoint locations, supported flows, etc… as all of that is advertised at the metadata endpoint of the token issuer, and could be picked up by any client adhering to the spec

You’re right that OAuth2, at least in the original specification, does nothing to specify how a resource server should validate a token — or even what a token is.

Yeah, I was pretty surprised by that... and good point about the metadata add-on... we don't implement that (since we aren't, currently, a public ID system so any clients for us are heavily controlled).

👀 That metadata is a lot of variables! No wonder there's so much variability in client libraries 😂

Yeah, to be clear I’m not saying people are wrong about a universal client being hard to pull off… I just don’t think it’s due to the standard itself, but rather implementations that choose to ignore it 😅

I spent the last 7-8 years working with these things, both at identity vendors and at “end-users”, before I got interested in authorization and policy as code 🙂

yes, it would be nice if everyone followed specs, but the real world has other plans - at least the general flow is understood by everyone, rather than people inventing their own not-quite-OAuth approaches

just out of curiosity — what “implementation” is it that has an out-of-spec refresh token flow? that’s awful

can't speak for @U0WL6FA77 - but just based on my experience Drift, Zoom and Qualtrics' APIs have their own way of refreshing tokens, I'm not that familiar with the spec, but we definitely have 3 slightly different ways of dealing with these services

(Qualtrics' being the most "fun" - their API exposes their regional infra, and despite claiming that there are global auth endpoints, they're not - you have to parse data center IDs from error responses and/or response headers)

> This isn’t so much a fault of oauth2 I would argue with it. The oauth2 documentation is one of the worst one. At least for me. Totally academic style. Long documentation and after read it you have learn almost nothing practical.

That’s what I’d expect/want from a formal specification. Practical guides and tutorials may complement that of course

Havne’t seen keycloak mentioned but it has both oauth client and servers.

I haven’t tried it, but my guess is it’ll only improve CPU bound tasks, so not necessarily web services or anything like that. it would bring it the Native Image perf closer to normal Java JIT, so I believe is like a 10 - 20% difference

whoaaaaa

Where do I find out more about this paid version? Is there individual or only enterprise?

I think it's here: https://shop.oracle.com/apex/f?p=dstore:2:0::NO:RIR,RP,2:PROD_HIER_ID:123775488249871532594385

Looks like it's 30$ per year for desktop deployments, or about 300$ a year for server deployments. I'm not sure how that applies to native images though.