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.

Sign up for GitHub

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

Jump to bottom

x/tools/cmd/present: bad websocket origin when origin=localhost and config.Origin=127.0.0.1 #8096

Closed
kortschak opened this issue May 26, 2014 · 14 comments
Closed

x/tools/cmd/present: bad websocket origin when origin=localhost and config.Origin=127.0.0.1 #8096

kortschak opened this issue May 26, 2014 · 14 comments
Labels
FrozenDueToAge

Comments

@kortschak
Copy link
Contributor 

What does 'go version' print?
go version go1.2.1 linux/amd64
go version go1.3beta2 +77632b0a1c94 Sun May 25 08:38:59 2014 +1000 linux/amd64

go.tools/cmd/present$ hg identify 
b6a3b105fbb0 tip

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Start present in go.talks with no command line options.
2. Attempt to play a snippet.

What happened?

Nothing in play window. Log output:
2014/05/26 13:57:16 bad websocket origin: http://localhost:3999

What should have happened instead?

No log output and a successfully played snippet.

Please provide any additional information below.

This is worked around by changing the -http parameter to "localhost:3999". The
issue was introduced with bda3619e7a2c which makes a naive comparison of host rather
than a comparison of destination IP or other.
@gopherbot
Copy link
Contributor

Comment 1:

CL https://golang.org/cl/98570044 mentions this issue.

@adg
Copy link
Contributor

adg commented May 26, 2014

Comment 2:

Another workaround is that the present tool could issue an HTTP redirect to point the
browser at the address given on the command line.
This does break -http=:3999, but maybe it should be broken? Ie, maybe you should have to
explicitly name the host on which you want to expose an arbitrary code execuction vector?

@kortschak
Copy link
Contributor Author

Comment 3:

Breaking -http=:3999 (or equivalent - it could be made explicit with -http=0.0.0.0:3999)
would make me very sad, particularly given the opportunities the NaCl support offers in
a teaching environment - the motivation for my NaCl support CLs was use of present in
workshops and tutorials.

@mikioh
Copy link
Contributor

mikioh commented May 27, 2014

Comment 4:

I'd personally prefer to add "-origin" flag to go.tools/cmd/present for letting the
program know what's the origin of RFC 6454.

@kortschak
Copy link
Contributor Author

Comment 5:

Is that in addition or instead. If instead, it still leaves the issue of dealing with
the logic of sorting out who to trust.

@mikioh
Copy link
Contributor

mikioh commented May 27, 2014

Comment 6:

As an additional option. Without that option present runs strictly. With that option
present runs on the target network environment with a bit flexible namespace, DNS
name/literal IP address - web origin, mapping.

@mikioh
Copy link
Contributor

mikioh commented May 27, 2014

Comment 7:

Labels changed: added repo-tools.

@adg
Copy link
Contributor

adg commented May 27, 2014

Comment 8:

Re #3: you could still listen on your public interface, you would just need to specify
the address of that interface explicitly on the command line.

@rsc
Copy link
Contributor

rsc commented May 27, 2014

Comment 9:

Labels changed: added release-none.

Status changed to Accepted.

@kortschak
Copy link
Contributor Author

Comment 10:

adg, I don't think I have enough of a handle on what you want to do to deal with this (I
feel like I'm cooking in someone else's kitchen here), so I think I'll pass, but leave
CL98570044 up unless your think it should be abandoned.

@gopherbot
Copy link
Contributor

Comment 11:

CL https://golang.org/cl/102770046 mentions this issue.

@adg
Copy link
Contributor

adg commented May 28, 2014

Comment 12:

Dan, I want to make this usable, but it also needs to be secure.
I think specifying the IP of the public interface on the command line is not such an
onerous task. However if it is indeed too hard, we could add a -public bool flag that
just listens on the first available public IP address and prints that address to the
console.
Would that solve your problem?

Owner changed to @adg.

@kortschak
Copy link
Contributor Author

Comment 13:

I am happy to provide a public interface IP. I was having confounding problems testing
mikio's proposal, but having got around that I see how this works now. Thanks.

@mikioh
Copy link
Contributor

mikioh commented Jun 2, 2014

Comment 14:

This issue was closed by revision golang/tools@96cece0.

Status changed to Fixed.

@mikioh mikioh changed the title go.tools/cmd/present: bad websocket origin when origin=localhost and config.Origin=127.0.0.1 x/tools/cmd/present: bad websocket origin when origin=localhost and config.Origin=127.0.0.1 Jul 30, 2015
@golang golang locked and limited conversation to collaborators Aug 5, 2016
@rsc rsc unassigned adg Jun 23, 2022
tmc pushed a commit to tmc/presentx that referenced this issue Jun 19, 2024
@cixtor
go.tools/{cmd/present,playground/socket}: add orighost flag to handle…
4fc3c02 
… the web origin more flexible

Also fixes the following nits;
- literal IPv6 address handling
- URL host component handling in the case of a wildcard listen
- URL port component handling in the case of no port component in origin

Fixes golang/go#8096.

LGTM=dan.kortschak, adg
R=adg, golang-codereviews, dan.kortschak
CC=golang-codereviews
https://golang.org/cl/102770046
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mikioh @rsc @kortschak @adg @gopherbot