:mixed doesn't allow insecure GET

[eostrom]

If I'm understanding the documentation right, this configuration should allow (and maybe enforce) HTTP for /login requests via the GET method:

config.middleware.use(Rack::SslEnforcer, :only => [%r{^/login}], :mixed => true)

However, when I try to GET /login, I am redirected to HTTPS. The :mixed option is checked only in enforcement_non_ssl?, which is called only if enforce_ssl? returns false. But since enforce_ssl? doesn't check :mixed, it returns true, and enforcement_non_ssl? never runs.

[rymai]

Hi,

this feature was merged, but to be honest I'm not quite sure what's the correct behavior.

In your example, it should redirect all http PUT and POST requests on /login to https requests? Right?

I'm really wondering why this feature is needed in the first place?

[eostrom]

My client wants to minimize use of SSL. So, for example, he wants to present the login form via HTTP but have it submitted via HTTPS (and then return to HTTP on success). At the moment both actions use the same URL. We could change the submission URL, but :mixed seemed like an easy way to acccomplish the goal. Only it turns out it isn't.

My impression is that the original submitter was using resource-based routes (in Rails) and wanted to be able to do something similar. Say, a "view user" page via HTTP and an "update user" action that allows you to change your password via HTTPS.

I like the idea of being able to use different protocols for different methods, but I'm not sold on the current design and implementation.

[rymai]

I couldn't agree more..

I'll try to fix this if you can wait until this evening (CET).

On 19 avr. 2011, at 06:36, [email protected] wrote:

My client wants to minimize use of SSL. So, for example, he wants to present the login form via HTTP but have it submitted via HTTPS (and then return to HTTP on success). At the moment both actions use the same URL. We could change the submission URL, but :mixed seemed like an easy way to acccomplish the goal. Only it turns out it isn't.

My impression is that the original submitter was using resource-based routes (in Rails) and wanted to be able to do something similar. Say, a "view user" page via HTTP and an "update user" action that allows you to change your password via HTTPS.

I like the idea of being able to use different protocols for different methods, but I'm not sold on the current design and implementation.

Reply to this email directly or view it on GitHub:
#21 (comment)

[rymai]

Hi,

I've just pushed a commit that should fixed the behavior of the :mixed option: d5b3bb3

Let me know what do you think of it now.

[lardawge]

@eostrom You are using it incorrectly. Don't include it in the :only array. You will be able to PUT or POST to the /login url securely without any magic and the GET will be forced http.
@rymai You actually broke it with that commit.

BTW it was my implementation. So basically the point is to leave PUT and POST methods alone just because of restful routes. Documentation could probably use some further clarification on how to use it.

[lardawge]

Here is the original commit: SHA: cb2959a
It is working flawlessly on a very large production site.

[eostrom]

@lardawge Thanks for the clarification. It seems like if I don't pass an :only argument, it will apply the :mixed behavior to /login, but also to every other URL. That's not what I was looking for, although I understand that it meets your needs.

I'd prefer that the :mixed parameter apply to the URLs specified by :only/:except. I'm not demanding anyone implement that for me. I was just trying to understand what the code is supposed to do, and whether it does it.

You mentioned the latest commit broke your expectations of :mixed; could you describe what broke?

[lardawge]

Mixed is a mixed version of strict so by default will make every request redirect to http unless you pass in specific paths using :only. From you description, you want login to be GET#login => insecure, POST#/login => secure. Don't pass in anything to :only but set mixed to true. Then any other paths you want to secure you would pass in using the :only option. In your login form you would need to pass a protocol into the url helper login_url(:protocol => 'https'). This should automatically redirect back to http if the redirect path is not used in only.

What I just described is exactly how I use the mixed option and why I implemented it. There are about 12 sections of the site I use it on that have this need. Because of mixed content warnings form ads I cannot go full ssl and I need it to redirect back to http.

The commit I referred to that broke this, made all my tests fail because it now ignores :only for get requests if :mixed => true.

[lardawge]

As a correction to the above, you will need something in :only for mixed or strict to work which makes sense... There would be no reason for the plugin otherwise.

[parhamr]

This reflects an overall design issue with the gem; it effectively whitelists paths or hosts for HTTPS, but allows exceptions for requests that can be HTTP. What is more useful is a behavior like the ssl_requirement plugin that works with Rails 2, in which you can define all three scenarios: ssl_required, ssl_allowed, and ssl_exceptions.

I’ve built a quick fork that provides this ability: https://github.com/parhamr/rack-ssl-enforcer

Its configurations accept paths or hosts that must be http or https, and then allows all other requests to maintain their current protocols.

It’s not fully tested or integrated with the leading features of this Rack gem, but I think it adequately adjusts the logic.

[rymai]

Hi,

I'm closing this thread due to inactivity. Also, the gem has received many improvements since then so it's most likely that the original use case can now be implemented.

Feel free to re-open (or open a new pull-request directly) if you feel there's still something to change in the gem.