Skip to content
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

[FEAT] additional WS authentication cookie configurations #5131

Merged
merged 1 commit into from
Feb 26, 2024

Conversation

aricart
Copy link
Member

@aricart aricart commented Feb 26, 2024

[FEAT] this change adds user_cookie, pass_cookie, and token_cookie to the WS configuration block - these mirror the behavior of jwt_cookie. If the options are not specified by the client but the server is has them configured, a WS connection will lookup values for the corresponding options under the HTTP cookie. This simplies websocket applications by allowing the HTTP application to set cookies that provide authentication details.

Simplifies #5047

Signed-off-by: Alberto Ricart aricart@synadia.com

@aricart aricart requested a review from a team as a code owner February 26, 2024 16:52
Copy link
Member

@derekcollison derekcollison left a comment

Choose a reason for hiding this comment

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

Some questions / comments.

Also want @kozlovic to take a peek.

Looks good though and agree would be good addition.

server/client.go Outdated Show resolved Hide resolved
server/client.go Outdated Show resolved Hide resolved
// Name of the cookie, which if present in WebSocket upgrade headers,
// will be treated as Token during CONNECT phase as long as
// "auth_token" specified in the CONNECT options is missing or empty.
TokenCookie string
Copy link
Member

Choose a reason for hiding this comment

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

Should we encourage this? I feel it should not be used and in my mind is deprecated. WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is the perfect location for users to provide a non-nats JWT for callout to process.

Copy link
Member Author

Choose a reason for hiding this comment

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

(this is why I thought this was a good thing to do)

Copy link
Member

Choose a reason for hiding this comment

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

ok that make sense. So maybe we call that out in the comment, that this should not be a plain server wide token but something external that folks want passed to the auth callout service etc.

Copy link
Member Author

Choose a reason for hiding this comment

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

well, it can be anything they want, including a server-wide token even if that is discouraged.

Copy link
Member Author

Choose a reason for hiding this comment

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

(added a good comment line)

server/client.go Outdated
@@ -2029,6 +2029,22 @@ func (c *client) processConnect(arg []byte) error {
if ws := c.ws; ws != nil && c.opts.JWT == "" {
Copy link
Member

Choose a reason for hiding this comment

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

Why don't we consolidate everything under that first part of the if statement:

if ws := c.ws; ws != nil {
    if c.opts.JWT == _EMPTY_ {
        c.opts.JWT = ws.cookieJwt
    }
    if c.opts.Username == _EMPTY_ {
        c.opts.Username = ws.cookieUsername
    }
    ...
}

server/websocket.go Outdated Show resolved Hide resolved
server/client.go Outdated
@@ -2026,9 +2026,25 @@ func (c *client) processConnect(arg []byte) error {
}

// If websocket client and JWT not in the CONNECT, use the cookie JWT (possibly empty).
if ws := c.ws; ws != nil && c.opts.JWT == "" {
if ws := c.ws; ws != nil && c.opts.JWT == _EMPTY_ {
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure if my earlier comment was properly posted. Trying again:

Why don't we consolidate everything under that first part of the if statement:

if ws := c.ws; ws != nil {
    if c.opts.JWT == _EMPTY_ {
        c.opts.JWT = ws.cookieJwt
    }
    if c.opts.Username == _EMPTY_ {
        c.opts.Username = ws.cookieUsername
    }
    ...
}

Basically, no need to check for ws := c.ws; ws != nil every time.

Copy link
Member Author

Choose a reason for hiding this comment

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

didn't complete it yet.. Now it is in

…ie` to the WS configuration block - these mirror the behavior of `jwt_cookie`. If the options are not specified by the client but the server is has this configured, a WS connection will lookup values for the corresponding options under the HTTP cookie. This simplies websocket applications by allowing the HTTP application to set cookies that provide authentication details.
Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

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

LGTM

@derekcollison derekcollison merged commit 8721d74 into main Feb 26, 2024
4 checks passed
@derekcollison derekcollison deleted the allow-other-ws-cookies branch February 26, 2024 22:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants