feat: allow bypassing current CORS magic based on template config #18706
Conversation
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
coderd/workspaceapps/proxy.go
Outdated
| // If passthru behavior is set, disable our CORS header stripping. | ||
| if cors.HasBehavior(r.Request.Context(), codersdk.CORSBehaviorPassthru) { | ||
| fmt.Println("not modifying headers!!!") | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Was this the main change to fix things?
There was a problem hiding this comment.
Discussed on slack but for record keeping:
Yes, that and the owner client in apptest.go.
Without changing the owner client from sdk client to app client the template id was different in the test setup where we try to set the templates cors behaviour vs in the actual code path where we check the cors behaviour on a template. For tests that were using that owner client.
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
cstyan
changed the title
cstyan
changed the title
cstyan
changed the title
🚀 Deploying PR 18706 ... |
| @@ -323,6 +324,37 @@ func (s *Server) workspaceAppsProxyPath(rw http.ResponseWriter, r *http.Request) | |||
| s.proxyWorkspaceApp(rw, r, *token, chiPath, appurl.ApplicationURL{}) | |||
| } | |||
|
|
|||
| // determineCORSBehavior examines the given token and conditionally applies | |||
| // CORS middleware if the token specifies that behavior. | |||
| func (s *Server) determineCORSBehavior(token *SignedToken, app appurl.ApplicationURL) func(http.Handler) http.Handler { | |||
There was a problem hiding this comment.
I don't know all the details behind when a token is issued. For example, if user 1 has an app with a share level of authenticated (or same but shared port), how can user 2 access the app? We need the signed token to grab the CORS behaviour, but if the user just goes to the apps externally accessible URL, will the correct token be issued?
Solves #15096
This is a slight rework/refactor of the earlier PRs from @dannykopping and @Emyrk:
Rather than having a per-app CORS behaviour setting and additionally a template level setting for ports, this PR adds a single template level CORS behaviour setting that is then used by all apps/ports for workspaces created from that template.
The main changes are in
proxy.goandrequest.goto:a) get the CORS behaviour setting from the template
b) have
HandleSubdomainbypass the CORS middleware handler if the selected behaviour ispassthruc) in
proxyWorkspaceApp, do not modify the response if the selected behaviour ispassthru