1

I'm working on a Rails 3.1.0 app that needs to have ssl in some pages depending on the user.

I setted config.force_ssl to false in config/enviroments/staging.rb. Added a before filter that decides whether or not to redirect to http. The redirect works in development if I clean the cache.

The thing is in staging, it results in a redirect loop. I believe that force_ssl uses a permanent redirect, therefore when the DNS is asked about a page in my app, it still tries to redirect to the page with ssl. Does this make any sense?

What are my options?

EDIT

I cleaned the cache. This only solves the problem the first time I enter the page. Lets say I refresh all cache and enter the http page. This displays the http page. When I exit the page, enter another page that has ssl and try to go back to the http page, the infinite redirect starts again.

The solution I implemented was to redirect to a unsafe subdomain. Let's call it 'unsafe'. So when I need to redirect to a http page, I redirect to http://unsafe.mydomain.com. This solves the infinite redirect, but some https pages are still being cached.

I guess the real question is when is it useful to use :status => :moved_permanently because It seems it causes the page to cache and it becomes dificult to clean this cache?

e3matheus
  • 2,112
  • 1
  • 20
  • 28

1 Answers1

2

Firstly, why are you not just forcing SSL for all pages? There is very little performance overhead but running in mixed mode you introduce a the potential of leaking what you thought were secure cookies if you're not careful. SSL everywhere :)

Now to your question, I doubt this has anything to do with DNS and is more likely to do with the regex of pattern matching logic around when it should redirect. Does it include the hostname/domain? If so does it match the domain you run as in staging?

Glenn Gillen
  • 471
  • 2
  • 7
  • Mostly agreed, but rather than the regex, it probably has something to do with the [permanent redirect](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2): "*The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs*". – Bruno May 04 '12 at 11:56
  • All the pages were being force by SSL. I hate doing this patches. Just that we integrated a SMS payment service(paygol) that the only way to implement it, is through an iframe. The service does not have ssl so internet explorer wont render it in a secure page. – e3matheus May 04 '12 at 22:15
  • @e3matheus, it's actually a good thing to tell the browser to keep using SSL. That's the point of [HSTS](http://stackoverflow.com/a/10448364/372643). (Perhaps [this](http://webmasters.stackexchange.com/a/28443/11628) could be interesting to you too.) Don't put an HTTPS iframe into a plain HTTP page: this defeats the point of them using SSL, since the user won't be able to check whether they're using SSL. That's just bad practice. – Bruno May 04 '12 at 23:15
  • I think I confused you. It's not a https frame inside a http page. It's a https page with an http frame. That was the problem. If the service had SSL, everything would work and I would need to redirect to a http page. – e3matheus May 04 '12 at 23:25
  • It seems the problem is that the app is HTTPS but the payments provider only gives the option of embbeding HTTP in the iframe. So yeah its mixed content... – Agush May 05 '12 at 00:02
  • @Agush, payments providers should really only use HTTPS. Ideally, they shouldn't even be in an iframe (like 3-D Secure does unfortunately), they should have their own page so that you can check *which* HTTPS site you're typing your data in. – Bruno May 05 '12 at 08:48