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

Prevent client from including a request authorization header #38

Closed
hueniverse opened this issue Sep 11, 2015 · 6 comments
Closed

Prevent client from including a request authorization header #38

hueniverse opened this issue Sep 11, 2015 · 6 comments
Assignees
Labels
Milestone

Comments

@hueniverse
Copy link
Member

@hueniverse hueniverse commented Sep 11, 2015

No description provided.

@hueniverse hueniverse self-assigned this Sep 11, 2015
@hueniverse hueniverse added this to the 0.4.0 milestone Sep 11, 2015
@devinivy

This comment has been minimized.

Copy link
Member

@devinivy devinivy commented Sep 12, 2015

What's the reasoning here? I guess I'm not sure what the relationship is meant to be between existing auth strategies on routes and the auth strategy used to authenticate the socket connection.

@hueniverse

This comment has been minimized.

Copy link
Member Author

@hueniverse hueniverse commented Sep 12, 2015

The entire connection must have a single auth otherwise the security properties of this connection are undefined and fluid.

@devinivy

This comment has been minimized.

Copy link
Member

@devinivy devinivy commented Sep 12, 2015

Are credentials used to authenticate the socket connection also used with requests to routes over sockets? I mean, how would a route authentication strategies be applicable at all over sockets? This is very confusing to me. For example, I might have different bearer tokens for different routes based upon the auth strategies that are used for those routes. And if I can provide those tokens, then what's the problem?

@hueniverse

This comment has been minimized.

Copy link
Member Author

@hueniverse hueniverse commented Sep 12, 2015

The WebSocket connection behaves like a single endpoint for authentication purposes. This is not a blank channel to send random HTTP requests over, each with their own headers. I have never seen a design where a single client uses multiple authentication credentials against one server.

So if your requirements are to authenticate a single client using different credentials for different endpoints, this would not be the right solution for you. I am not going to allow changing authentication state once a channel is initialized.

@devinivy

This comment has been minimized.

Copy link
Member

@devinivy devinivy commented Sep 12, 2015

This makes more sense after seeing that the credentials/artifacts from the original websocket request are used when invoking routes to bypass any existing auth strategy. I didn't know that was happening, or that server.inject() even allowed for that! I think the auth section of the nes docs gave me a little trouble too. In any case, thanks for bearing with my questions.

@hueniverse

This comment has been minimized.

Copy link
Member Author

@hueniverse hueniverse commented Sep 12, 2015

Happy to take a PR to make things clearer. The docs are not really for users at this point. They are mostly for me to keep track of everything I'm doing. At some point someone will need to write a proper guide for this module... It got big FAST.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.