You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a kuberneties environment where I will be running multiple code-server containers (one per user)
I have created a ingress 'overlay' for the code-server "/login" which (after confirming the users identification against our OAuth2 server) grabs the password for the user's code-server, hashing it, and sets it has the users code-server-session cookie, before returning the to code-server proper. This IS working and means we can set ANY authentication system we like (SSO in our case, so users often are already authenticated!)
This has works very well, though I find that code-server has some very specific 'requirements' for the argon2 has it requires.
Too low a iteration, parallelism, or memory and it just rejects it provided hash cookie, redirecting back to the "/login" web overlay, so as to try again. (and getting into a redirect loop, until browser breaks it!)
Unfortunate the "Go" language argon hash is woefully bad, in that it has no clean error handling and just CRASHES the program if it can't get the resources to hash the users password! This sets upper bounds on the argon2 hashing parameters we can use.
THE QUESTION: What exactly is the requirements code-server has for an acceptable argon2 hash?
Alternative (and this is not as good, as the hash become static until environment is restarted) Is their a way to get code-server to provide an acceptable hash instead of having the hash or some other session cookie?
is the password repeat failure limits saved to disk? If so where?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In a kuberneties environment where I will be running multiple code-server containers (one per user)
I have created a ingress 'overlay' for the code-server "/login" which (after confirming the users identification against our OAuth2 server) grabs the password for the user's code-server, hashing it, and sets it has the users code-server-session cookie, before returning the to code-server proper. This IS working and means we can set ANY authentication system we like (SSO in our case, so users often are already authenticated!)
This has works very well, though I find that code-server has some very specific 'requirements' for the argon2 has it requires.
Too low a iteration, parallelism, or memory and it just rejects it provided hash cookie, redirecting back to the "/login" web overlay, so as to try again. (and getting into a redirect loop, until browser breaks it!)
Unfortunate the "Go" language argon hash is woefully bad, in that it has no clean error handling and just CRASHES the program if it can't get the resources to hash the users password! This sets upper bounds on the argon2 hashing parameters we can use.
THE QUESTION: What exactly is the requirements code-server has for an acceptable argon2 hash?
Alternative (and this is not as good, as the hash become static until environment is restarted)
Is their a way to get code-server to provide an acceptable hash instead of having the hash or some other session cookie?
is the password repeat failure limits saved to disk? If so where?
Beta Was this translation helpful? Give feedback.
All reactions