Code-server argon2 Hash requirements.

[antofthy]

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?

[code-asher]

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 to htpasswd), 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.

[code-asher]

Also, it might be better to have an authenticating system outside of code-server, and forgo code-server's cookie altogether. Sounds like you might already have the infrastructure to make that happen, but maybe there are complications that are forcing you to do this hybrid auth setup.

[antofthy]

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.

[antofthy]

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!

[antofthy]

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_/login

HTTP/2 302 
date: Mon, 23 Jun 2025 00:51:54 GMT
content-type: text/html; charset=utf-8
location: /
set-cookie: code-server-session=%24argon2id%24v%3D19%24m%3D20480%2Ct%3D3%2Cp%3D2%24or7Rc9IElHDM5JWUxGcgdA%24yevw2uxwTjmRLIJT%2F1mmRtD8mh3C5OvistEnrcNepho; Path=/; Max-Age=28800; Secure
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

HTTP/2 302 
date: Mon, 23 Jun 2025 00:51:55 GMT
content-type: text/plain; charset=utf-8
content-length: 40
location: ./?folder=/home/user
vary: Accept, Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

HTTP/2 302 
date: Mon, 23 Jun 2025 00:51:55 GMT
content-type: text/plain; charset=utf-8
content-length: 49
location: ./login?folder=/home/user&to=
vary: Accept, Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

[code-asher]

Huh...that is strange. Thinking out loud...

1. If hashed-password is set then then code-server does a simple string comparison between the cookie value and the config value. argon2 is not invoked at all.
2. If hashed-password is not set but password is set, then code-server does invoke argon2.verify() to compare the cookie value to the plain text password value, but it only does this if the cookie value starts with $, otherwise it immediately returns false.

I think 2 is the setup you have. So either the cookie is somehow unset during the redirect or argon2.verify() is sometimes returning false, somehow? Makes no sense. We might have to add logging to code-server to figure it out.

I experimented but I have not been able to reproduce unfortunately.

[antofthy]

Thank you for the information about hashed-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.

[code-asher]

Yup from my testing it is after decoding. And yup the limit is in memory so it resets if code-server restarts.

I opened #7396.

[antofthy]

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 a HASHED_PASSWORD environment variable is used code-server logs this fact.
BUT is hashed-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...

[code-asher]

Glad to hear it!!

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

Oops, I will fix that right now. Thanks for spotting it!

[antofthy]

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.

[code-asher]

Oh! Huh. Node failed to respond with connections is not something that is supposed to happen, it implies something very wrong, since it means getConnections is not responding for five seconds. Not responding with the number of connections, not even responding with an error.

I have no idea how that happens. It feels like something low level. I am not sure if it is related to the redirect issue, but it seems possible. Could even be a Node bug maybe??

[antofthy]

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?

[code-asher]

/login should have no effect on the active connections code, that is entirely separate as far as I recall. The only thing it does is check the rate limit and set a cookie when it gets a POST request so I think you should be good in that regard.

Actually, that makes me realize the limiter should be having any effect on what you are doing because we are not rate limiting authentication attempts using a cookie (although we should be), at the moment it is only on POST requests to /login.

I wonder if there is some kind of resource starvation going on? Is it running out of memory or file descriptors or something? Not sure why it would not error if that was the case though. 🤔

[antofthy]

I figured out from code exploration that the limiter was only in /login. So not an issue.
The bare minimal overlay on a basic minimal code-server seems to have no problem.
As such it may be you are right and it might be resource limitations. I'll continue my investigations.

Okay it is happening. pod is now using 150Mi memory, but its limit is currently 2Gi so no resource limitations.

[2025-07-01T06:44:36.666Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'
[2025-07-01T06:44:37.001Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'
[16:44:37] [10.220.5.105][33dd206b][ExtensionHostConnection] New connection established.
[16:44:37] [10.220.5.105][33dd206b][ExtensionHostConnection] <11324> Launched Extension Host Process.
[2025-07-01T06:44:37.175Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'
File not found: /usr/local/code-server-4.101.1-linux-amd64/lib/vscode/extensions/merge-conflict/dist/browser/mergeConflictMain.js
[2025-07-01T06:45:35.365Z] debug 0 active connections
[2025-07-01T06:45:57.176Z] debug heartbeat
[2025-07-01T06:45:57.176Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'

Note the File not found in this log! If it helps.
At least I am beyond what I thought was some sort of 'cookie' problem, as session-cookies are matching.

Hmm... There is a 'node' process that is defunct! Could that be the cause?

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   4124  2560 ?        Ss   Jun30   0:00 su -c exec "$0" "$@" www-data -- /usr/local/bin/start-code-server -s
root          14  0.0  0.2 267000 36036 ?        S    Jun30   0:02 apache2 -DFOREGROUND
www-data      26  0.0  0.0 267040 12420 ?        S    Jun30   0:00 apache2 -DFOREGROUND
www-data      27  0.0  0.4 1115200 65480 ?       Ssl  Jun30   0:00 /usr/local/code-server/lib/node /usr/local/code-server /var/www --bind-addr 0.0.0.0:8080 --auth password --disable-update-check --disable-telemetry --disable-getting-started-override --app-name Software Development Environments
www-data      60  0.0  0.7 11824644 114460 ?     Sl   Jun30   0:30 /usr/local/code-server-4.101.1-linux-amd64/lib/node /usr/local/code-server-4.101.1-linux-amd64/out/node/entry
www-data     115  0.0  0.4 1133856 78864 ?       Sl   15:08   0:05 /usr/local/code-server-4.101.1-linux-amd64/lib/node /usr/local/code-server-4.101.1-linux-amd64/lib/vscode/out/bootstrap-fork --type=ptyHost --logsPath /var/www/.local/share/code-server/logs/20250701T150701
www-data     126  0.0  0.0      0     0 ?        Z    15:08   0:00 [node] <defunct>
www-data     174  0.0  0.0   7428  3968 pts/1    Ss+  15:08   0:00 /usr/bin/bash --init-file /usr/local/code-server-4.101.1-linux-amd64/lib/vscode/out/vs/workbench/contrib/terminal/common/scripts/shellIntegration-bash.sh
www-data   11324  0.0  0.5 22159948 84184 ?      Sl   16:44   0:00 /usr/local/code-server-4.101.1-linux-amd64/lib/node --dns-result-order=ipv4first /usr/local/code-server-4.101.1-linux-amd64/lib/vscode/out/bootstrap-fork --type=extensionHost --transformURIs --useHostProxy=false

Looks like process 126 has been inherted by process 1, which means its original parent had died, before it exited,
process 1 does not have a auto wait. Perhaps something I need to look at. but should not effect things.
There is a bout 10 threads attached to each listed 'node'.

# pstree -p 1
su(1)─┬─apache2(14)───apache2(26)
      ├─node(27)─┬─node(60)─┬─node(115)─┬─bash(174)
      │          │          │           ├─{node}(116)
      │          │          │           ├─{node}(117)
      │          │          │           ├─{node}(118)
      │          │          │           ├─{node}(119)
      │          │          │           ├─{node}(120)
      │          │          │           ├─{node}(121)
      │          │          │           ├─{node}(122)
      │          │          │           ├─{node}(123)
      │          │          │           ├─{node}(124)
      │          │          │           ├─{node}(125)
      │          │          │           └─{node}(175)
      │          │          ├─node(11324)─┬─{node}(11325)
      │          │          │             ├─{node}(11326)
      │          │          │             ├─{node}(11327)
      │          │          │             ├─{node}(11328)
      │          │          │             ├─{node}(11329)
      │          │          │             ├─{node}(11330)
      │          │          │             ├─{node}(11331)
      │          │          │             ├─{node}(11332)
      │          │          │             ├─{node}(11333)
      │          │          │             └─{node}(11334)
      │          │          ├─{node}(61)
      │          │          ├─{node}(62)
      │          │          ├─{node}(63)
      │          │          ├─{node}(64)
      │          │          ├─{node}(65)
      │          │          ├─{node}(66)
      │          │          ├─{node}(67)
      │          │          ├─{node}(68)
      │          │          ├─{node}(69)
      │          │          └─{node}(70)
      │          ├─{node}(50)
      │          ├─{node}(51)
      │          ├─{node}(52)
      │          ├─{node}(53)
      │          ├─{node}(54)
      │          ├─{node}(55)
      │          ├─{node}(56)
      │          ├─{node}(57)
      │          ├─{node}(58)
      │          └─{node}(59)
      └─node(126)

Hmm... suddenly It is working again! Arrggghhh....
Logs since the end of the previous log...

[2025-07-01T07:10:49.351Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'
[2025-07-01T07:10:49.376Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'
File not found: /usr/local/code-server-4.101.1-linux-amd64/lib/vscode/node_modules/vsda/rust/web/vsda.js
[17:10:49] [10.220.5.105][108ab8cf][ManagementConnection] New connection established.
[2025-07-01T07:10:49.662Z] debug isCookieValid: 'true' = '4182704edf1d88197ed579cb928ef8a5' '4182704edf1d88197ed579cb928ef8a5'
[17:10:49] Using cached extensions scan result system file:///usr/local/code-server-4.101.1-linux-amd64/lib/vscode/extensions
[17:10:49] Using cached extensions scan result user file:///var/www/.local/share/code-server/extensions/extensions.json
[17:10:49] [10.220.5.105][822131d7][ExtensionHostConnection] New connection established.
[17:10:49] [10.220.5.105][822131d7][ExtensionHostConnection] <11389> Launched Extension Host Process.
[2025-07-01T07:10:50.503Z] debug Adding session to session registry: /tmp/vscode-ipc-05bbe777-72f4-49e6-8d28-a44a49834133.sock
[17:10:50] Using cached extensions scan result system file:///usr/local/code-server-4.101.1-linux-amd64/lib/vscode/extensions
[17:10:50] Terminal profile not validated zsh [ 'zsh' ]
[17:10:50] Terminal profile not validated tmux [ 'tmux' ]
[17:10:50] Terminal profile not validated pwsh [ 'pwsh' ]
[17:10:50] Terminal profile not validated fish [ 'fish' ]
[17:10:50] Using cached extensions scan result system file:///usr/local/code-server-4.101.1-linux-amd64/lib/vscode/extensions
[17:10:50] Using cached extensions scan result system file:///usr/local/code-server-4.101.1-linux-amd64/lib/vscode/extensions
[17:10:51] Terminal profile not validated zsh [ 'zsh' ]
[17:10:51] Terminal profile not validated fish [ 'fish' ]
[17:10:51] Terminal profile not validated tmux [ 'tmux' ]
[17:10:51] Terminal profile not validated pwsh [ 'pwsh' ]
[17:10:52] Using cached extensions scan result system file:///usr/local/code-server-4.101.1-linux-amd64/lib/vscode/extensions
[17:10:54] Terminal profile not validated zsh [ 'zsh' ]
[17:10:54] Terminal profile not validated fish [ 'fish' ]
[17:10:54] Terminal profile not validated tmux [ 'tmux' ]
[17:10:54] Terminal profile not validated pwsh [ 'pwsh' ]
[2025-07-01T07:11:48.796Z] debug 2 active connections
[2025-07-01T07:11:48.796Z] debug heartbeat

[antofthy]

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.

[antofthy]

Well you were right... it all came down to resource limits.    Arrrgghhhh...
It is all very stable again, after a long throughout testing.

For a period I even thought perhaps it was nodejs interactions, as we also install a v18 of Node, while code-server is using Node v22

Thank you greatly for your help, especially with regards to the session-cookie. We no longer use a argon2 hash for this, just set a random string as the "hashed-password" in the code-server config.yaml file, every time code-server is restarted.
Our overlay of the "/login" path of code-server with out own web service doing authentication, and session-cookie setting, is working great. As users are generally already authenticated, they rare need to authenticate, but can jump straight into the server.

[code-asher]

Awesome glad to hear it!!

[antofthy]

Just as a update. The system is now live with around 990 student accounts.

As mentioned we use kuberneties ingress to replace the "/login" sub-path of code-server, with out own login server, replacing the code-server login with out own.

Once the user is authenticated, and the web service re-directed to the users own code-server (with a "/login" path), then the users session key is read from the pre-set in "HOME/.config/code-server/config.yaml" during container start up. The file only contains a single line hashed-password: {long sting of hex-digits}

System is simple, uses our own local authentication methods (user is probably already signed in) almost fool proof.

The only problem encountered is ensuring this file is not accidentally removed or modified by the user. If it isn't right their container is restarted, so a new session key is generated for the newly re-started code-server to use.

It s a lot better than the previous (docker based) system, we previously used requiring the user to copy and paste the provided password for them to login. They authenticate as per the reset of the university systems, as normal, and never see a code-server login prompt!

[code-asher]

Very slick!!