What exactly is the requirements code-server has for an acceptable argon2 hash

We are calling out to the package without any arguments so it uses whatever defaults they have configured. They say the defaults are "according to the security recommendations by the team that develops Argon2" and you can see them here:https://github.com/ranisalt/node-argon2/wiki/Options.

Is their a way to get code-server to provide an acceptable hash

It might be a good idea to add a way to have code-server take your password and spit out the hash (similar tohtpasswd), is that what you mean? Then as part of the setup you could have it output the right hash for the password you generated and you use that in the cookie.

I wonder though if you really need to use the hashed password and could use a plain text one instead? If an attacker gains access to the password file, they already have access to the container, and if the passwords are unique they have no further utility. There could be an angle I am not seeing though.

Is the password repeat failure limits saved to disk

No, the rate limiting is purely in memory.

Replacing the "/login" sub-path of code server, and using our authentaction system, and setting the session-cookie, just seemed
to be simpeist. Then have no need to handle sessions ourselves, as we previously did.

There will be a LOT (500+) users, though we expect only a maximum of around 60 at any one time.

Previously we were creating the container and assigning a random password that we give to the authenticated user, for them to copy-n-paste so as to login to code-server. It needed a redis database to hold information about the user, even though once the user was logged into code-server they no longer needed to use the authentation system. That system has been in use for more than 5 years, in a docker environment.

Now we are migrating to a kuberneties system, and want to simply pick up the already generated password (from the code-server config file) set the session cookie, and direct them to code-server. No more copy-n-pasting. They just go to their development environment,
If they don't have a session cookie, code-server jumps to "/login" which is overlaid by our auth system. They are authenticated (often already done), and the sesstion cookie set and sent back to code-server top level (just as the "/login" sub-system of code-server does).

Users never actually need to know their code-server password! They just login to our systems as normal (if not already), and they have access to their code-server (and no one elses).

Most of the time code-server accepts the hash we create from the password. I have confirmed the session-cookie hash I generate verifies against the password stored in the code-server.

But when code-server doesn't accept the session cookie as valid, it jumps back to the '/login' sub-path, their auth is transparently and quickly confirmed, and a new hash of their password is set as the cookie, before it again ends them back to code-server top-level.

What is happening is that when the cookie is not accepted. No re-hashing of the password gathered from the code-server config, ever seemed to be accepted as valid! This results in a endless browser re-direction loop (until browser put a halt to it).

At first I thought the cookie was being reset and lost. But it is still present when the users browser is redirected back to our auth system, and I have again manually confirmed that the refected cookie hash, does verifiy against the config password.

Then I thought it was the argon2 params being checked, and found to not be good enough as I had been forced to use less secure parameters (thus the original request). That has now been resolved. Example params$argon2id$v=19$m=20480,t=3,p=2$

Now I got the feeling that the code-server is internally using a slightly different password to what it had written in its config file.
OR it is in some sort of "I am not accepting anything anymore" mode.

Basically the hashed password I set the cookie to, is either accepted first time, It never accepted at all,
OR no matter now many times I give it a hashed copy of the password as a session-cookie, it gets rejected.

And yes The system would be a LOT simpler if the session cookie was simply the code-server generated password
it saves in the config file. I actually destroy that file every-time code-server is restarted, so a new password is generated on startup.
It should not matter what that password is, it is collected hashed and used to set the session cookie. It just sometimes works, and sometimes doesn't.

Okay... Found the faults. I had HttpOnly set on the cookie.
And I was not URL escaping the hash when setting the cookie...

I don't know why it was sometimes working, while other times it didn't.
Still. I believe I have it all working now, and will be doing more tests Monday to unsure that is the case.

On monday I will post here some of the password/cookie testing 'curl' commands I used to debug this, but right now -- weekend! Yeah!

This is driving me batty!
The cookie gets accepted by code-server, then gets rejected by it!

I call my replacement login which sets a cookie...
This then jumps to the top-level (the actual code-server)
which accepts the cookie and re-directs to "./?folder=/home/user" the users home directory
BUT THEN it seems to immediately reject the cookie again, and re-directs back to '/login'
Arrrgghhhhh.....

# curl --head -L --cookie-jar cookie_jar --cookie cookie_jar https://{code-server.domain_/loginHTTP/2 302 date: Mon, 23 Jun 2025 00:51:54 GMTcontent-type: text/html; charset=utf-8location: /set-cookie: code-server-session=%24argon2id%24v%3D19%24m%3D20480%2Ct%3D3%2Cp%3D2%24or7Rc9IElHDM5JWUxGcgdA%24yevw2uxwTjmRLIJT%2F1mmRtD8mh3C5OvistEnrcNepho; Path=/; Max-Age=28800; Securestrict-transport-security: max-age=31536000; includeSubDomainsx-content-type-options: nosniffHTTP/2 302 date: Mon, 23 Jun 2025 00:51:55 GMTcontent-type: text/plain; charset=utf-8content-length: 40location: ./?folder=/home/uservary: Accept, Accept-Encodingstrict-transport-security: max-age=31536000; includeSubDomainsx-content-type-options: nosniffHTTP/2 302 date: Mon, 23 Jun 2025 00:51:55 GMTcontent-type: text/plain; charset=utf-8content-length: 49location: ./login?folder=/home/user&to=vary: Accept, Accept-Encodingstrict-transport-security: max-age=31536000; includeSubDomainsx-content-type-options: nosniff

Thank you for the information abouthashed-password I will switch to using that.
2 is what I have been trying to do. I assume the '$' is check AFTER the cookie has been URL decoded.

Extra logging under would be useful. I was using "--log debug" (from years ago) but I suddenly realised it is not listed in "--help" output. Switching to "--verbose".

Having it log if it hits the 2 per minute or 12 per hour limit would be good too. Having some way of turning that OFF for debugging would be good too. I gather that limit is reset if code-server restarted. That may be causing half my frustration during testing.

Okay I have it working! /login is overlaid with our own authentication system, by our kuberneties ingress system.

When user and domain is validated the completely random (long hex key)hashed-password is retrieved, and set as teh session cookie, and user is redirected to code-server top level.

One point. if aHASHED_PASSWORD environment variable is used code-server logs this fact.
BUT ishashed-password is retrieved from code-servers "config.yml" file, it reports...

- Authentication is enabled- Using password from /var/www/.config/code-server/config.yaml

Even though there is no password set in that file (just the hashed-password) all else is set via command line.

Thank you for your help...

Oh hum....
Well I thought it was all working... And it was all working... for about 1/2 hour.
All our discussions have been thinking that it was the cookie... It isn't the cookie is set and is correct...

First I added some temporary debug loging to isCookieValid() in node/util.js

case"SHA256":isValid=(0,safe_compare_1.default)(cookieKey,hashedPasswordFromArgs);logger_1.logger.debug(`isCookieValid: '${isValid}' = '${cookieKey}' '${hashedPasswordFromArgs}'`);

That way I can see if it is 1 getting the cookie, see what the cookie is, and that it is validating correctly!

So when I jump first jump into code-server (an old cookie set) I see in the logs...

[2025-06-26T23:37:11.622Z] info  HTTP server listening on http://0.0.0.0:8080/[2025-06-26T23:37:11.623Z] info    - Authentication is enabled[2025-06-26T23:37:11.623Z] info      - Using password from /var/www/.config/code-server/config.yaml[2025-06-26T23:37:11.623Z] info    - Not serving HTTPS[2025-06-26T23:37:11.623Z] info  Session server listening on /var/www/.local/share/code-server/code-server-ipc.sock[2025-06-26T23:49:27.019Z] debug heartbeat[09:49:27] Remote configuration data at /var/www/.local/share/code-server[09:49:27] process arguments: {  'hashed-password': '11aee663933b8dda079448c22d04fa3b',  config: '/var/www/.config/code-server/config.yaml',  _: [ '/var/www' ],  'bind-addr': '0.0.0.0:8080',  auth: 'password',

Then the failure due to the cookie being wrong (or empty if not set).

[2025-06-26T23:49:27.269Z] debug isCookieValid: 'false' = 'b81aeb28285ade37aba61aabda312793' '11aee663933b8dda079448c22d04fa3b'[2025-06-26T23:49:27.270Z] debug redirecting from / to ./login

All good. My /login replacement authenticates the user, and sets the right cookie.

[2025-06-26T23:49:27.567Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[2025-06-26T23:49:27.571Z] debug redirecting from / to ./?folder=/var/www[2025-06-26T23:49:27.588Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[2025-06-26T23:49:27.599Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[09:49:27] [WebClientServer] x-forwarded-host: s357751.--redacted--[09:49:27] [WebClientServer] x-forwarded-port: 443[09:49:27] [WebClientServer] host: s357751.--redacted--[09:49:27] [WebClientServer] Request URL: /?folder=/var/www, basePath: ., remoteAuthority: remote:443

and so on... ALL WORKING PERFECTLY... (PS I am GMT+10)

Later after some time... (went to morning tea) I com back and as soon as I start working...
It redirected me back to login! routine
MY login determined the cookie is still set correctly, so generated a warning page (rather than create a redirrction loop)
MY logs for login authentication.

2025/06/27 10:28:37 WARNING: User's session-cookie already set!2025/06/27 10:28:37 You appear to be already logged in!  This is precaution against a looping redirection failure

But in code-server logs...

[2025-06-26T23:54:52.378Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[09:54:54] [10.220.5.105][d0ba5804][ExtensionHostConnection] <260> Extension Host Process exited with code: 0, signal: null.[2025-06-26T23:55:16.841Z] debug Node failed to respond with connections; assuming zero[2025-06-27T00:27:48.888Z] debug heartbeat[2025-06-27T00:27:48.889Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[2025-06-27T00:28:29.200Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[2025-06-27T00:28:37.886Z] debug isCookieValid: 'true' = '11aee663933b8dda079448c22d04fa3b' '11aee663933b8dda079448c22d04fa3b'[2025-06-27T00:28:53.891Z] debug Node failed to respond with connections; assuming zero

The first line was last interaction before morning tea...
Then at 2025-06-27T00:27:48.888Z I get a heartbeat as I returned...
The cookie though comes out as correct, but during those 3 attempts. I am being returned BACK to /login.
It does NOT log that it is redirecting, or log anything at all... but it is redirecting back to /login, despite the cookie being Valid!

From this point on... When ever I go back to the top level '/' It always redirects back to /login

Strange When I jump to "/?folder=/var/www" It worked! Again!

BUT later (when window 'disconnected, and needed to reconnect...
It failed completely and always tried to go to /login, regardless of If I jumpt to URL '/' or '/?folder=/var/www'
Most annoying, expecially as my logging shows the cookie I set is found by code-server and isCookieValid().

Actually it does not appear to be even trying to test the cookie in this 'permanent' failed state.
and redirects with extra get args, and a empty 'to=' EG: my login code gets.. a request of
GET /login?folder=/var/www&to=

If I don't hear from you by monday, I'll start adding loggin on EVERY redirect I can find to try and backtrack the cause.

So what would you like me to do to help you?

Last time we stopped idle code-server virtual machines, after a couple of hours inactivity according to the heart beat file. (Just an open terminal was not enough to keep heart beat working, which is why it is 2 hours). Users would then restart them, and could re-start them any time they like. (Running on Docker)

This time though we are planing to keep all the users code-server virtual machines running indefinably, as it would mean the authentication system does not need any access to control the virtual environment. The users code-server is already running. Basically as this is a lot more difficult to do under kuberneties.

Note that once it gets into this state, restarting code-server does NOT fix the problem, even in a reset browser.
It still re-directs users back to /login. This is immeditally after the initial start up 'info' in logs...

[10:15:17] Extension host agent started.[10:15:17] No extensions are marked as removed.[2025-06-30T00:15:32.063Z] debug isCookieValid: 'true' = '5110066eca166d0a1a56eeb804d95fdf' '5110066eca166d0a1a56eeb804d95fdf'[2025-06-30T00:16:17.641Z] debug 0 active connections

Perhaps code-server /login does something to reset the '0 active connections' condition, which of course I would not be doing?

Back tracking to my proof of concept version. (very small). This uses a plain code-server container...
codeserver_deploy.yaml.txt

Then has the kubernetes ingress overlay the '/login' with a VERY small bash-socat webserver to just set the cookie, on ANY request under the './login' path.
web_cookie_redir.sh.txt

It works perfectly fine. Even after running all day! If I try to 'logout' of code-server, it jumps to '/login' cookie gets set again
and it is logged in again... I'm leaving it running overnight, and will look at it again in the morning.

Of course this has a fixed argon2 hashed password, which code-server accepted just fine. It has none of the Authentication, find users home, retrieve the code-server password (or hashed-password), set a cookie,
and redirect back to code-server top-level, of the production '/login' overlay. Which was all written in Go Lang, statically compiled, container.

Tomorrow I am stripping down my user development environment, with code-server in apache-php image to try and ensure it working in the same setup.