-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with Auth in Singularity 1.2.0 #2134
Comments
So there is a bunch here and I can provide a more detailed response tomorrow. but some shorter highlights:
|
Great news, thank you! |
1.3.0 jars should be on maven central in a bit, just released. Gonna close this one for now and we can open new/specific issues as they pop up 👍 |
Amazing, thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey
We're currently adding another layer of security into our current cluster, but have already faced several issues.
We've managed to add webhook into our, I'd say, thingy, which is serving login page and goes into LDAP for user verification.
Output is pushed into cookie and passed to Singularity.
First issue -- we were unable to feed that to Singularity through header, 'cause js scripts which are 'talking' to api were ignoring forwarded authorization header and used
null
instead -- that's why we've used cookie wrapping.Second -- any emailed action doesn't have
singularityUserId
anymore (actually this is a long-runner, unrelated to current issue and is observed at least for last 12 months). CansingularityUserId
be also parsed from http://URI/singularity/api/auth/user from user:id field if auth is enabled?And the main issue is that I don't get how groups are working.
Users who are enrolled into jitaGroups+requiredGroups are unable to browse UI at all, everything blows up with something like
Although everything is working as intended (I mean -- whole our machinery with blows and whistles).
Users who are enrolled into
globalReadOnlyGroups
+requiredGroups
are able to pause/unpause jobs and edit anything (wut?).Users who are enrolled into
adminGroups
+requiredGroups
-- can do pretty much the same as RO users do.Can you please clarify how this feature is working (or not)? Can we assign more granular rights to groups? Thanks!
The text was updated successfully, but these errors were encountered: