Fixes issue #7544 which adding a cookie-suffix flag

[Timon-D3v]

I added the cookie-suffix flag and environment variable. This adds the possibility for the user to fix the issue but the default option would still be the same (Best for backwards compatibility).

This PR does fix the issue #7544 where a subdomain would not use the right cookie because of the wildcard cookie set by a domain of higher order.

[code-asher]

Sorry it took so long to review this. I like the direction we are headed!

[code-asher]

This pulls off the environment variable, but if someone sets --cookie-suffix then this will not pick up anything since it is on the flag and not in the env.

What if we made this a function? Something like:

function cookieKey(suffix) {
 // return the key name here
}

And then where we need it we can call it like:

cookieKey(req.args["cookie-suffix"])

[Timon-D3v]

Oops, yeah your right... I somehow thought this would adress that (but it is the other way around XD):

if (process.env.COOKIE_SUFFIX) {
  args["cookie-suffix"] = process.env.COOKIE_SUFFIX
}

But I dont quite get what you want to do with the function.

Do you want to do something like this:

// From 
export const CookieKeys = {
  Session: `code-server-session${process.env?.CODE_SERVER_COOKIE_SUFFIX? "-" + process.env?.CODE_SERVER_COOKIE_SUFFIX : ""}`,
}


// To
export function CookieKeys(suffix: string) {
  ...
  return { Session: "..." }
}

Or more like this:

function getCookieSessionName(): string {
  if (process.env?.CODE_SERVER_COOKIE_SUFFIX) {
    return `code-server-session-${process.env.CODE_SERVER_COOKIE_SUFFIX}`
  } 

  if (args["cookie-suffix"]) {
    return .....
  }

  return "code-server-session";
}

export const CookieKeys = {
  Session: getCookieSessionName(),
}

Because from what I understand, it seems like you want to do something like the first example which does not make a lot of sense to me. This should be set one time at start up and then not be changed and also a function would mean that you had to replace every call to this to a function.

Lastly, how could i get the cli-arguments? Is there also something like process.cliArgs or a variabel that i have to import from somewhere?

[code-asher]

Yup the second one, exactly.

So we would end up with a function like:

function getCookieSessionName(suffix?: string): string {
  return suffix ? `code-server-session-${suffix}` : "code-server-session";
}

And we could call it like:

getCookieSessionName(req.args["cookie-suffix"])

in place of CookieKeys.Session

[code-asher]

Oh and to answer the second question, the arguments are placed on the request, there is no global for them.

[Timon-D3v]

Ohh ok, that makes perfect sense to use it on req. But then we really cannot initialize it on startup but have to call the

getCookieSessionName(req.args["cookie-suffix"])

on every request. Don't you think that is suboptimal or is there plain no other way?

To clarify what I understand is that you would make it like this:

export const CookieKeys = {
  getCookieSessionName: function(suffix?: string): string {
    return suffix ? `code-server-session-${suffix}` : "code-server-session";
  }
}

And then you would call it when needed in node/http.ts:

// ...
const isCookieValidArgs: IsCookieValidArgs = {
  passwordMethod,
  
  // Before:
  // cookieKey: sanitizeString(req.cookies[CookieKeys.Session]),
  
  // After:
  cookieKey: sanitizeString(req.cookies[getCookieSessionName(req.args["cookie-suffix"])])
  
  
  passwordFromArgs: req.args.password || "",
  hashedPasswordFromArgs: req.args["hashed-password"],
}
// ...

[code-asher]

Personally I think there is no need to embed it in CookieKeys, we only ever have the one cookie name, so I am not sure we why even had it as an enum before.

The overhead from this is probably so minuscule it may not even be possible to measure it. But, we could instead calculate it once and pass it through using the request.

We could add cookieSessionName: string here:

code-server/src/node/http.ts

Lines 38 to 43 in 472bf8a

	export interface Request {
	args: DefaultedArgs
	heart: Heart
	settings: SettingsProvider<CoderSettings>
	updater: UpdateProvider
	}

And then here we could calculate the name in a const and attach it to the request like we do with the other variables here:

code-server/src/node/routes/index.ts

Lines 62 to 80 in 472bf8a

	const updater = new UpdateProvider("https://api.github.com/repos/coder/code-server/releases/latest", settings)
	const common: express.RequestHandler = (req, _, next) => {
	// /healthz|/healthz/ needs to be excluded otherwise health checks will make
	// it look like code-server is always in use.
	if (!/^\/healthz\/?$/.test(req.url)) {
	// NOTE@jsjoeio - intentionally not awaiting the .beat() call here because
	// we don't want to slow down the request.
	heart.beat()
	}
	// Add common variables routes can use.
	req.args = args
	req.heart = heart
	req.settings = settings
	req.updater = updater
	next()
	}

[Timon-D3v]

That makes a ton of sense to me now. Also i didn't understand that you wanted to get rid of the CookieKeys but now all you answers are clear to me.

The overhead from this is probably so minuscule it may not even be possible to measure it. But, we could instead calculate it once and pass it through using the request.

I also think it would not make a big difference but since it takes so long to load (even if it is faster when built) I think it does not hurt to do it that way.

Do you agree? If so I would start to work on it :)