Is this something we could fix inwebsocket?

I actually don't know. That's just copied from the existing code; I wanted to limit my changes to just session token stuff.

I can see the logic here, but I think it would make more sense to call provider.SetSessionToken() and implement the method on FixedSessionTokenProvider. Other providers may choose to ignore it or do something else. If this, for example, was a file provider underneath, one may wish to write the token rather than have it be ephemeral.

I actually want to go the other direction and drop this method entirely. The abstraction here is a session tokenprovider, not a session tokenstore.

I kept the method around to keep this PR relatively minimal in size, but we are almost always* using this method to set a fixed session token at start of day. There just aren't really many circumstances where you find out the session token later.

• 2 exceptions I can think of:

1. coder login where we get the token pasted in, and then check it. But even in that case, you can create the Client after the token is pasted in. It's not really safe (and has not been) to useSetSessionToken() after the client has been referenced by other goroutines, so it's better to create a new Client.

2. Token exchange based on VM identity credentials --- that is the subject of the PR stacked on top of this one. This is based on anonymousExchangeToken function callbacks that callSetSessionToken() before the PR above this one, but that's pretty fragile and not threadsafe.

Alright, that makes sense to me and I'm fine with the approach. I'd like it if we could mark this method deprecated, however, and mention that it replaces the provider.

(IIRC the Go standard deprecation comment is, on a new line:// Deprecated: Use ... instead.

Question: What's the use-case for this method?

Suggestion: Can we make it a private method? At least a comment would be good, and I'd suggest renamingNo ->NoSet/Without.

I'm happy to change the name.

The use-case for this method is in the PR stacked on top of this one.

Exchanging a VM identity document for a session token involves a call to Coderd. We need this option to call coderd without a session token to ensure we don't create a re-entrant loop in the token exchange code.

If we implementSet like proposed earlier, we can make theSessionToken field private and avoidGet here.

There are still some random bits of code that do oddball stuff like putting the session token in a Cookie jar, rather than using the custom header. Until that stuff is cleaned up we still need an escape hatch to just get the session token from the Client.