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

Issue691 allowed origins #693

Merged
merged 2 commits into from
Jul 1, 2016
Merged

Conversation

meejah
Copy link
Contributor

@meejah meejah commented Jun 15, 2016

Fixes for #691, allowed-origin checks.

(In-progress).

@codecov-io
Copy link

codecov-io commented Jun 16, 2016

Current coverage is 59.99%

Merging #693 into master will increase coverage by 0.72%

@@             master       #693   diff @@
==========================================
  Files            66         66          
  Lines         10740      10854   +114   
  Methods           0          0          
  Messages          0          0          
  Branches       1643       1657    +14   
==========================================
+ Hits           6366       6512   +146   
+ Misses         3861       3799    -62   
- Partials        513        543    +30   

Powered by Codecov. Last updated by 998e378...2ef13a6

# assign websocket_origin as the triple (scheme, host,
# port) but that would change what's in onConnect's
# information (for .origin). Worth breaking the API for?
if have_origin:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@oberstet should we do either of the above XXX things? Or should I just change the comments?

@eastein
Copy link

eastein commented Jun 16, 2016

IMO, treating the Origin as a triple is pretty much required by the RFC and to make things safe.

@meejah
Copy link
Contributor Author

meejah commented Jun 16, 2016

For the "built in" checks, I believe I am treating it as a triple that must match -- my question is more regarding the API presented via ConnectionRequest to onConnect. For example, we could maintain compatibility by leaving .origin as a string with the host, and add .scheme and .port or similar -- or force everyone to (possibly) change existing code and make .origin a (scheme, host, port) triple.

Certainly the latter seems "more correct", but might not be worth breaking code. I guess a "third way" would be to add a new .websocket_origin as a triple, deprecate .origin (removing .origin entirely at some point).

self.assertFalse(_is_same_origin('https://example.com:80/', 443, policy))
self.assertFalse(_is_same_origin('https://example.com/', 80, policy))
self.assertFalse(_is_same_origin('http://example.org/', 80, policy))
self.assertFalse(_is_same_origin('http://ietf.org/', 80, policy))
Copy link

Choose a reason for hiding this comment

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

Additional valid URIs, though i'm unsure if these would be possible to spoof into the Origin given any browser:

  • http://example.com./
  • //example.com/
  • http://@example.com

@meejah
Copy link
Contributor Author

meejah commented Jun 22, 2016

@oberstet what do you think of 671266f (comes with example code)? This allows the existing API to function while also allowing one to be explicit about ports. Perhaps I should also remove the explicit "scheme" check (in _is_same_origin()), too? (And rely on the reg-ex?). Currently, this will not allow you to accept e.g. an http origin at an https websocket endpoint (or vice-versa) -- but that probably shouldn't be allowed anyway.

@oberstet
Copy link
Contributor

oberstet commented Jul 1, 2016

@meejah The pragmatic approach looks good to me. Filtering on origin in a way is snake oil anyway: a non-browser client can fake it. Could you squash the PR and merge?

@meejah meejah force-pushed the issue691-allowed-origins branch 2 times, most recently from 06966b1 to 20322ed Compare July 1, 2016 16:52
@meejah meejah merged commit d7c40e0 into crossbario:master Jul 1, 2016
@meejah meejah deleted the issue691-allowed-origins branch July 1, 2016 17:53
apevec pushed a commit to rdo-common/python-autobahn that referenced this pull request Sep 14, 2016
- Apply patch to correct allowedOrigin validation. See bz:1359792, bz:1359791 and crossbario/autobahn-python#693
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.

5 participants