Duane Johnson
2005-Jun-30 21:10 UTC
Hopping between http and https - Rails best practices?
Is there a best practice for the common requirement that a site move from http:// to https:// for secure payment while keeping the session? I''m having trouble finding an easy way to hop between the non-ssl and the ssl part of the site. Does anyone have any suggestions? Duane Johnson (canadaduane)
Demetrius Nunes
2005-Jun-30 21:28 UTC
Re: Hopping between http and https - Rails best practices?
Duane Johnson wrote:> Is there a best practice for the common requirement that a site move > from http:// to https:// for secure payment while keeping the session? > I''m having trouble finding an easy way to hop between the non-ssl and > the ssl part of the site. Does anyone have any suggestions? > > Duane Johnson > (canadaduane)Here''s what I did: - Added a filter that would redirect from http to https for the secure actions - Added a defaut_url_options to set the protocol to https on those secure actions Like this: SECURED_ACTIONS = [ ... ] before_filter :require_ssl, :only => SECURED_ACTIONS def require_ssl unless @request.ssl? redirect_to :protocol => ''https://'', :action => action_name end end def default_url_options(options) SECURED_ACTIONS.include?(options[:action]) ? { :protocol => ''https://'' } : { :protocol => ''http://'' } end This assured me that every link generated to the secured actions would use https and if by any chance a secured action was requested with http it would redirect itself to https. My session data is not lost when the protocol is changed. Hope that helps, Dema http://dema.ruby.com.br/
Duane Johnson
2005-Jun-30 21:56 UTC
Re: Re: Hopping between http and https - Rails best practices?
On Jun 30, 2005, at 3:28 PM, Demetrius Nunes wrote:> Duane Johnson wrote: > >> Is there a best practice for the common requirement that a site >> move from http:// to https:// for secure payment while keeping >> the session? I''m having trouble finding an easy way to hop >> between the non-ssl and the ssl part of the site. Does anyone >> have any suggestions? >> Duane Johnson >> (canadaduane) >> > Here''s what I did: > > - Added a filter that would redirect from http to https for the > secure actions > - Added a defaut_url_options to set the protocol to https on those > secure actions<snip>> My session data is not lost when the protocol is changed. > > Hope that helps, > DemaThanks Demetrius, this is excellent. Why is it that you did not lose session data between servers? Are you using the exact same host, e.g. http://filmfury.com and https:// filmfury.com to get that nice side effect? Our secure certificate is currently for secure.filmfury.com... I''m not familiar enough with cookies to know if that would mean we get two different cookies (and hence two separate sessions) when a user crosses protocol boundaries. Is there a way to restore a session from a passed-in session id from the URL in case we do need to? Duane Johnson (canadaduane) _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Zach Thompson
2005-Jun-30 22:45 UTC
Re: Re: Hopping between http and https - Rails best practices?
On Jun 30, 2005, at 2:56 PM, Duane Johnson wrote:> On Jun 30, 2005, at 3:28 PM, Demetrius Nunes wrote:Duane Johnson wrote: >> >>> Is there a best practice for the common requirement that a site move >>> from http:// to https:// for secure payment while keeping the >>> session? I''m having trouble finding an easy way to hop between the >>> non-ssl and the ssl part of the site. Does anyone have any >>> suggestions? >>> Duane Johnson >>> (canadaduane) >>> >> Here''s what I did: >> >> - Added a filter that would redirect from http to https for the >> secure actions >> - Added a defaut_url_options to set the protocol to https on those >> secure actions<snip> >> My session data is not lost when the protocol is changed. >> >> Hope that helps, >> Dema > Thanks Demetrius, this is excellent. > > Why is it that you did not lose session data between servers? Are you > using the exact same host, e.g. http://filmfury.com and > https://filmfury.com to get that nice side effect? > > Our secure certificate is currently for secure.filmfury.com... I''m not > familiar enough with cookies to know if that would mean we get two > different cookies (and hence two separate sessions) when a user > crosses protocol boundaries. > > Is there a way to restore a session from a passed-in session id from > the URL in case we do need to?Wow - the timing of this thread is unbelievable. I am in the final hours of a project that has been going on since last year, and getting the billing form to run through a secure server was one of the last few things I needed to do. I was about to start working on it when I noticed this email... Anyway, I looked at the cross-host problem and got something working. You can get the session id with cookies[:_session_id] So if you make a url from the first host like "/something/test?_session_id=#{cookies[:_session_id]}" then this action should get you into the session on another host: def test cookies[:_session_id] = @params[:_session_id] redirect_to :action => ''whatever'' end At least it seemed to work when I tested it. It might not be so good to have the session id in a url, but hopefully this gets you started with something. Zach
Matias Pelenur
2005-Jul-01 03:18 UTC
Re: Re: Hopping between http and https - Rails best practices?
Duane, In general, cookies have a particular domain they are assigned to, and that domain is the only one that can read them back. You may be able to share cookies between secure.filmfury.com and filmfury.com by setting your cookie path to be something like ".filmfury.com". I assume the Rails has a cookie API to do such a thing. This is kind of a long shot and I know not too much information. I would suggest reading up on the HTTP cookie spec. You could also use one of those http trace programs on your browser to see what it sends back when you browse the different sites (your browser adds an HTTP-Cookie or some such header to the GET requests). Hope this helps a bit, Matias Duane Johnson wrote:> On Jun 30, 2005, at 3:28 PM, Demetrius Nunes wrote: > >> Duane Johnson wrote: >> >>> Is there a best practice for the common requirement that a site move >>> from http:// to https:// for secure payment while keeping the >>> session? I''m having trouble finding an easy way to hop between the >>> non-ssl and the ssl part of the site. Does anyone have any suggestions? >>> Duane Johnson >>> (canadaduane) >>> >> Here''s what I did: >> >> - Added a filter that would redirect from http to https for the secure >> actions >> - Added a defaut_url_options to set the protocol to https on those >> secure actions > > <snip> > >> My session data is not lost when the protocol is changed. >> >> Hope that helps, >> Dema > > > Thanks Demetrius, this is excellent. > > Why is it that you did not lose session data between servers? Are you > using the exact same host, e.g. http://filmfury.com and > https://filmfury.com to get that nice side effect? > > Our secure certificate is currently for secure.filmfury.com... I''m not > familiar enough with cookies to know if that would mean we get two > different cookies (and hence two separate sessions) when a user crosses > protocol boundaries. > > Is there a way to restore a session from a passed-in session id from the > URL in case we do need to? > > Duane Johnson > (canadaduane) > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Duane Johnson
2005-Jul-01 06:16 UTC
[SOLVED] Re: Hopping between http and https - Rails best practices?
On Jun 30, 2005, at 9:18 PM, Matias Pelenur wrote:> Duane, > In general, cookies have a particular domain they are assigned to, > and that > domain is the only one that can read them back. > > You may be able to share cookies between secure.filmfury.com and > filmfury.com by > setting your cookie path to be something like ".filmfury.com". I > assume the > Rails has a cookie API to do such a thing. > > This is kind of a long shot and I know not too much information. I > would suggest > reading up on the HTTP cookie spec. You could also use one of > those http trace > programs on your browser to see what it sends back when you browse > the different > sites (your browser adds an HTTP-Cookie or some such header to the > GET requests).Fantastic! Thanks to all who helped. I''ve made the changes as suggested by Matias and Demetrius. I found an old thread that explained the Rails code to apply Matias'' suggestion. Here''s what I did: I added the following to environment.rb so that all sessions would persist across the non-ssl filmfury.com and the ssl secure.filmfury.com domains: session_options = \ ::ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS session_options[:session_domain] = ".filmfury.com" And I also implemented Demetrius'' solution to linking between domains in a slightly modified form: These two methods are in application.rb: SECURE_ACTIONS = ["billing", "signup_step_one", "signup_step_two", "signup_step_three"] # Called as a before_filter in controllers that have some https:// actions def require_ssl unless @request.ssl? redirect_to :protocol => ''https://'', :action => action_name # Continue to render the action? No, so return false. return false end end def default_url_options(options) defaults = {} if USE_EXPLICIT_HOST_IN_ALL_LINKS # This will OVERRIDE only_path => true, not just set the default. options[:only_path] = false # Now set the default protocol appropriately: if SECURE_ACTIONS.include?(options[:action]) defaults[:protocol] = ''https://'' defaults[:host] = SECURE_SERVER if defined? SECURE_SERVER else defaults[:protocol] = ''http://'' defaults[:host] = NON_SECURE_SERVER if defined? NON_SECURE_SERVER end end return defaults end Then in my SignupController: before_filter :require_ssl, :only => [:signup_step_one, :signup_step_two, :signup_step_three] Short explanation: the default_url_options method will override the :only_path => true clause that seems to be the default in some cases. Doing so makes it possible for the :protocol and :host options to take effect. In other words, all links in the site (in production mode) are full paths that include the host and protocol. It seems like a necessary trade-off for making cross-domain links possible. I also added the USE_EXPLICIT_HOST_IN_ALL_LINKS in there so that I could turn the cross-domain linking on and off inside of the environment/production.rb and environment/development.rb config files. Thanks again to all who helped. You who make up this list are far better support than several corporate customer service centers I''ve tried to communicate with :) Duane Johnson (canadaduane) _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
David Teare
2005-Jul-01 17:11 UTC
Re: Re: Hopping between http and https - Rails best practices?
You should be okay as long as the cookie path is somecompany.com. The browser will send all cookies to a site where the "goto" URL ends with the domain name set in the cookie, ; if you go to secure.yahoo.com, it will send send a cookie that had domain=''yahoo.com''. This is why browsers don''t let you set a cookie with a single TLD, you always must specify at least one domain plus the TLD. On 30-Jun-05, at 11:18 PM, Matias Pelenur wrote:> Duane, > In general, cookies have a particular domain they are assigned to, > and that > domain is the only one that can read them back. > > You may be able to share cookies between secure.filmfury.com and > filmfury.com by > setting your cookie path to be something like ".filmfury.com". I > assume the > Rails has a cookie API to do such a thing. > > This is kind of a long shot and I know not too much information. I > would suggest > reading up on the HTTP cookie spec. You could also use one of > those http trace > programs on your browser to see what it sends back when you browse > the different > sites (your browser adds an HTTP-Cookie or some such header to the > GET requests). > > Hope this helps a bit, > Matias > > > Duane Johnson wrote: > >> On Jun 30, 2005, at 3:28 PM, Demetrius Nunes wrote: >> >> >>> Duane Johnson wrote: >>> >>> >>>> Is there a best practice for the common requirement that a site >>>> move >>>> from http:// to https:// for secure payment while keeping the >>>> session? I''m having trouble finding an easy way to hop between the >>>> non-ssl and the ssl part of the site. Does anyone have any >>>> suggestions? >>>> Duane Johnson >>>> (canadaduane) >>>> >>>> >>> Here''s what I did: >>> >>> - Added a filter that would redirect from http to https for the >>> secure >>> actions >>> - Added a defaut_url_options to set the protocol to https on those >>> secure actions >>> >> >> <snip> >> >> >>> My session data is not lost when the protocol is changed. >>> >>> Hope that helps, >>> Dema >>> >> >> >> Thanks Demetrius, this is excellent. >> >> Why is it that you did not lose session data between servers? Are >> you >> using the exact same host, e.g. http://filmfury.com and >> https://filmfury.com to get that nice side effect? >> >> Our secure certificate is currently for secure.filmfury.com... I''m >> not >> familiar enough with cookies to know if that would mean we get two >> different cookies (and hence two separate sessions) when a user >> crosses >> protocol boundaries. >> >> Is there a way to restore a session from a passed-in session id >> from the >> URL in case we do need to? >> >> Duane Johnson >> (canadaduane) >> >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >