Clojurians Log v2
off-topic
Just saw this: https://github.blog/changelog/2020-12-17-changes-to-code-search-indexing/
Not going to index repos that haven't seen a commit or shown up in a search result in a year.
I guess that's both good and bad: good that unmaintained projects stop showing up but bad (for Clojure) that very popular stable projects that are "done" may drop out of the results 😐
Github's action scheduled to run once a week imitating activity) 🤫
Seems a little strange; a project that doesn't change is definitionally easy to cache
They want to remove "not relevant" results from search index, not optimize delivery time
They have the "Archived" flag for non-relevant results, not?
there are popular clojure repos that are "archived"
(I guess that's a separate issue)
And there are also plenty of abandoned repos out there which have not (yet) been archived -- which is what they're aiming to exclude, I expect.
The way I read it, a repo is considered active if it has “shown up in a search result” — so if it shows up in a result, that extends its inclusion in the index by another year. Seems reasonable to me.
Sort of a long shot, but has anyone had to set up OAuth2 as a client in a web app that is multi-tenant and serves on a large number of different domains? I’m trying to figure out the best way to make this work without having to add dozens of different callback URIs to each OAuth provider (such as Google, LinkedIn, Facebook, etc).
You'll need a redirector.
One central place that just forwards to where it's supposed to be.
I built a product that was multi tenant a few years back and we registered separate oauth credentials with our identity provider for each tenant domain. I realize that's more work but the isolation we ended up with was nice. We then automated all aspects of tenant provisioning so adding a tenant was still as simple as entering a name and clicking a button
I should add: our apps fetched their config for a tenant (like the oauth credentials) from another service at runtime so there wasn't any need to update settings / secret files with new credentials for each tenant.
But as dominicm said, if you want just one then you'll need a redirect that inspects some aspect of the state query param to determine the original tenant I think
There's plenty of services that don't allow that kind of dynamic registration. Although it maybe depends on how you're isolating tenants too
So after thinking on it all day yesterday, I’m going down the route described above, namely encoding the origin domain into the state field sent to the auth server, and then writing an intermediate callback that will do nothing but decode the state, pull out the encoded origin domain, and redirect to the final callback at the correct domain.