-
Notifications
You must be signed in to change notification settings - Fork 133
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
Designs #27
Merged
Designs #27
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
## Authorize on connect | ||
|
||
When client side creates the WebSocket instance and connects to the subscriptions server, it must provide the authorization token, but there are some issues with that: | ||
|
||
1. It’s not possible to provide custom headers when creating WebSocket connection in browser. | ||
|
||
> related to https://github.com/apollostack/subscriptions-transport-ws/issues/50 , | ||
https://github.com/apollostack/subscriptions-transport-ws/pull/45 | ||
|
||
A possible workaround is to send the auth token in the url as query parameter and parse in on sever side while doing the connection handshake | ||
|
||
> (Note: graphql-subscription does not expose onConnection callback, only onSubscribe, which occur after the connection) | ||
|
||
2. You have to create the actual connection and then reject it in the server side if there is an error with the user’s authorization token. | ||
At the moment, graphql-subscription does not expose `unsubscribe` or `disconnect` feature for a connection (should be part of `onConnection`) | ||
|
||
> related to https://github.com/apollostack/subscriptions-transport-ws/issues/51 , https://github.com/apollostack/subscriptions-transport-ws/pull/17 | ||
|
||
3. At the moment, the client side can provide the “context” object for the subscription (and not for the connection), which can contain his auth token. | ||
|
||
|
||
Another option is to send the auth token from the client side on a separate message (like, `ON_INIT`) before creating the subscriptions. | ||
|
||
|
||
## Authorization Lifecycle | ||
|
||
Another issue is the lifecycle of the authorization token, there are some cases that needs a solution: | ||
|
||
1. How to handle invalidation of the auth token? | ||
If the client side logout from the application, it’s the client side’s responsibility to disconnect the WebSocket. | ||
|
||
2. How to handle expiration of token? | ||
At the moment, If the client side’s token no longer valid, it should logout the user and disconnect the token. | ||
|
||
|
||
## Authorization Validation | ||
|
||
What is the server side’s responsibility when dealing with authorized WebSocket and subscriptions? | ||
|
||
If the client side does not disconnects the WebSocket when needed (for example, on logout or on expiration), and the WebSocket remains open, the client side will receive the publications of it’s existing subscriptions. | ||
It’s not an option to validate the auth token on the server before each publication, for each user that subscribed. | ||
|
||
|
||
## Existing WebSocket Authorization Solutions | ||
|
||
* Socket.io-auth (https://github.com/facundoolano/socketio-auth ) | ||
* Provides a similar flow to onConnection and onAuthorize with a token, the server can validate and authorize the connection only when the connection created. | ||
* The auth token send via a custom WebSocket message. | ||
* Features callbacks for `onAuthorize`, `onAuthorized`, `onReject`, `postAuthenticate`. | ||
* Sockjs-node (https://github.com/sockjs/sockjs-node#authorisation ) | ||
* Does not provide a built-in solution and suggest a self-implemented authorization. | ||
* https://gist.github.com/subudeepak/9897212 | ||
* https://auth0.com/blog/auth-with-socket-io/ | ||
* https://auth0.com/blog/auth-with-socket-io/ | ||
* Suggests using authorization on connection using url parameter with the auth token. | ||
|
||
|
||
## Implementation possibility: | ||
|
||
* Client creates a networkInterface with WebSocket client, and provides the auth token using one of the following: | ||
* URL parameter with the auth token. | ||
* Custom object that will be translated into INIT_MESSAGE and will be sent after initial connection handshake. | ||
* Server side “onConnection” fires and validate the token, if the token is invalid, it rejects the connection / disconnects the socket. | ||
|
||
#### Pros: | ||
|
||
* Simple to implement. | ||
* Server side - need to add “onConnection” callback with ability to reject the connection. | ||
* Client side - need to add ability to send custom object with the auth token (or take if from the requested URL). | ||
* Custom auth for each application. | ||
|
||
#### Cons: | ||
|
||
* Forces the client side to handle logout/expiration of the token | ||
* Server publications not validated. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth mentioning what Meteor does.
The DDP protocol itself has no concept of authentication. Authentication is done via normal method calls.
The Meteor DDP server implementation allows method calls to store state on the connection object representing the current user ID, which is accessible from other methods and publications. If the user ID ever changes, all publications are basically re-evaluated from scratch (inside the server). Nothing special is done on the server side to allow methods to notice if the user ID changes while they are running; however, methods run in series unless they explicitly ask to unblock the connection (and the client tries to not send login methods in parallel with other methods).
The Meteor Accounts package tracks DDP connections associated with resume tokens and disconnects them if the resume token associated with that connection is deleted from the database.
Personal opinion: having auth just be "another method" wasn't the best idea. It works better if it's an established-at-beginning-of-connection, disconnect-to-change thing. However, the general idea of having a way for changes to authn/authz to "rerun publishers" or "disconnect connections" is nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@glasser I'll merge the PR and then maybe you could PR your comment on top of it to add it to the right place?
I'm actually not sure what's the best format for collaborating on this, maybe comments on this PR is the best place? @helfer what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm I'll merge now anyway, at least so we'll have the folder itself.
we can still keep the discussion here or on related PRs that people do to it