Skip to content

chore: move app proxying code to workspaceapps pkg #6998

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Apr 5, 2023

Conversation

deansheather
Copy link
Member

@deansheather deansheather commented Apr 4, 2023

Moves path-app, subdomain-app and reconnecting PTY proxying to the new workspaceapps.WorkspaceAppServer struct. This struct does not interface with the database ever, in preparation for external workspace proxies.

Updates app logout flow to avoid redirecting to coder-logout.${app_host} on logout. Instead, all subdomain app tokens owned by the logging-out user will be deleted every time you logout and your browser will not do redirecting to each app host. This is in preparation for workspace proxies so we don't have to redirect the user to every single moon in a loop.

Tests will remain in their original package, pending being moved to an apptest package (or similar).

Closes #6914

Moves path-app, subdomain-app and reconnecting PTY proxying to the new
workspaceapps.WorkspaceAppServer struct. This is in preparation for
external workspace proxies.

Updates app logout flow to avoid redirecting to coder-logout.${app_host}
on logout. Instead, all subdomain app tokens owned by the logging-out
user will be deleted every time you logout for simplicity sake.

Tests will remain in their original package, pending being moved to an
apptest package (or similar).

Co-authored-by: Steven Masley <Emyrk@users.noreply.github.com>
@@ -0,0 +1,8 @@
package workspaceapps_test

// NOTE: for now, app proxying tests are still in their old locations, pending
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this will be part of moons?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBD exactly, but the unit tests will live in APGL and called from both APGL and enterprise coderd with embedded and external moons/workspace proxies.

Comment on lines 496 to 500
// TODO: Fix this later
// s.WebsocketWaitMutex.Lock()
// s.WebsocketWaitGroup.Add(1)
// s.WebsocketWaitMutex.Unlock()
// defer s.WebsocketWaitGroup.Done()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will cause leaks if merged before fixing this, right? We could just add a Close func to this server, which has it's own mutex and wait group for this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do that.

Question, why do we need a mutex and a wait group? Aren't wait groups already thread safe?

This code in the close locks the mutex then waits.

coder/coderd/coderd.go

Lines 809 to 811 in 7e0ea10

api.WebsocketWaitMutex.Lock()
api.WebsocketWaitGroup.Wait()
api.WebsocketWaitMutex.Unlock()

So if a new websocket comes in while we are closing, the new websocket conn gets block (trys to lock). Then the wait group finises, then the new websocket conn continues as the lock is freed.

I think this logic has some flaws, and just a waitgroup wouldn't fix all race conditions, but it keeps the same behavior and reduces some complexity.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've implemented it the exact same way as coderd does. I do agree that the mutex seems pointless and we can fix that if you want

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this crazy?
#7008

//
// The first 64 bytes of the key are used for signing tokens with HMAC-SHA256,
// and the last 32 bytes are used for encrypting API keys with AES-256-GCM.
type SigningKey [96]byte
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should rename this now that it does both signing/encryption.

How about, "SecurityKey"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other ideas:

  • "CryptoKey"
  • "AuthenticityKey" (since we only use this key to guarantee authenticity of payloads)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename is here: fe28e42

Copy link
Member

@Emyrk Emyrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

This all looks good. Things will likely change a bit as we make this support external proxies.

@Emyrk Emyrk merged commit eb66cc9 into main Apr 5, 2023
@Emyrk Emyrk deleted the dean/move-app-proxy-routes branch April 5, 2023 18:41
@github-actions github-actions bot locked and limited conversation to collaborators Apr 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move app/terminal serving code to workspaceapps package
3 participants