Skip to content
This repository has been archived by the owner on Mar 5, 2021. It is now read-only.

Support hosting the server on a single port and over https #105

Open
AgileJoshua opened this issue Feb 5, 2016 · 7 comments
Open

Support hosting the server on a single port and over https #105

AgileJoshua opened this issue Feb 5, 2016 · 7 comments

Comments

@AgileJoshua
Copy link
Contributor

In order to be more flexible about server hosting options. Requiring two ports makes it more difficult to host with shared hosting providers in case you don't want it running on your local machine.

@elisee
Copy link
Contributor

elisee commented Feb 5, 2016

The original reason for using a different port for builds is that it creates two separate origins, protecting Superpowers from the games and vice-versa (in terms of localStorage, for instance. Calling Sup.Storage.clear() in your game should not clear your Superpowers settings).

I don't know if there's a better solution but any change should take this into account.

@AgileJoshua
Copy link
Contributor Author

Not sure either that there is a better solution for localstorage when running over a single port, but I am putting together something for my own use, single port with ssl. A working version is here AgileJoshua/superpowers@1de58df

The only localstorage setting that exists for the server as far as I can see is "disable notifications". Very low impact of being cleared. The electron client is unaffected by the games/servers calling localstorage.clear since it is running from a different origin.

Are there other areas where a single port could cause issues?

@elisee
Copy link
Contributor

elisee commented Feb 5, 2016

The plan (#55) for user-specific settings going forward is to store them in localStorage.

What hosting provider prevents you from using multiple ports?

@AgileJoshua
Copy link
Contributor Author

From my research and attempts to do this Heroku, OpenShift and Azure App Services all have issues with opening multiple ports in their standard plans. They all use environment variables to let you know which port your app is to listen to and you only get one.

Obviously this could be solved with various proxying solutions or using multiple app hosts that share data. Having multiple hosts (one for build, one for main) would require changes in the client also.

For GGJ16 and the location I organised I set up an Azure host with some of the customizations I have committed. And everyone ran on the same central Superpowers host.

@elisee
Copy link
Contributor

elisee commented Feb 5, 2016

OK good to know! I imagine when proxying, the multiple origins are merged by the browser so we lose the benefits.

Hmmm... I guess your approach is the best we can hope for then! It supports having separate ports but doesn't enforce it. We could keep different ports as the default and document that they can be set to the same if needed, with a caveat. Care to submit a pull request?

@elisee
Copy link
Contributor

elisee commented Feb 8, 2016

As an interesting note for the future, I stumbled upon a draft spec (currently not implemented by any browser) for suborigins ("namespaced origins"): https://metromoxie.github.io/webappsec/specs/suborigins/ that would allow us to get rid of the 2 separate HTTP servers while keeping separate origins.

@curioussavage
Copy link

I know this issue is old but I keep forgetting to leave my own feedback. I am just fine with the current way of doing things. What I was doing when I was running superpowers on my server was just using subdomains. The only annoying thing was only the port is configurable. If the domain for the build server were configurable it would be just fine as is IMO.

I know one click hosting to something like heroku is cool but people who use platforms like that are usually more than capable of configuring nginx. I guess maybe the free tier is the draw. But OVH has vps for 3.50 which is dirt cheap.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants