nonce cookies not set if developing over HTTP

[download13]

If you take a look at the oauth utils you'll notice that the secure option for setting cookies is true.

Shouldn't this respond to the secure horizon option?

I'm developing an application over HTTP because it's a lot more convenient and the express server it's running from won't support HTTPS anyway (that's going to be nginx's job). Right now OAuth logins don't work at all because of this.

[deontologician]

ping @Tryneus

[Tryneus]

@download13 - while we could make this change, I'm not convinced it would help in your situation. If you do not already have your HTTPS proxy running, I imagine you would run into #508 instead. If you do have your HTTPS proxy running, it should work in either case, as the client is interacting over HTTPS (but if I'm not mistaken it would be vulnerable if we made this change as the cookie could then be exposed to MitM attacks over HTTP).

Let me know your thoughts on this if it's still an issue for you.

[download13]

It seems to me that there is an advantage to making developing with your framework as user-friendly as possible. If someone comes along who can't figure out how to set up nginx on their Windows development machine, that's one more person who just drops Horizon and goes to find another framework.

I'm all for forcing as much security as you can into production mode, but getting devs up and running as quickly and easily as possible is just as important if you want lots of people to start using Horizon (which I would love to see because these issues aside, it's pretty cool).

I probably don't have to tell you that as a developer, using a library where everything "just works" and you can immediately see it's utility and potential is a great feeling.

It doesn't have to be a security risk because secure should only be set to false during development. The only real danger is someone forgetting they left it set to false, but that can be mitigated by showing a warning message if !secure && NODE_ENV !== 'development' or something similar.

I think #508 should probably follow this pattern as well; allowing security to be turned off during development for the sake of convenience. Some OAuth providers may change http to https but at least developers can test their setup with one that doesn't (and I would hope some of the providers are smart enough to not do that for localhost and 127.0.0.1 redirect uris).

Just my two cents.

[deontologician]

I think the major thing is OAuth providers won't redirect to http, so we can allow it on our end, but it's going to cause a bug. Would it help if we print out an error if you try to use OAuth with --secure=false ?

[marshall007]

I don't think that's necessarily true. I'm fairly certain at least Twitter and GitHub allow you to specify localhost as your redirect_uri (without TLS). Providing no workaround for this and #508 during local development seems kinda bad. Consider also that the developer might be mocking out the calls to the OAuth provider for testing purposes.

[deontologician]

Ok, reopening