Kenny, Not sure if this helps but here is an approach I took with one of my recent applications that sounds at least similar to your situation. I too had a fairly basic application that employed Authlogic for authentication. I presume you're using the ubiquitous ssl_required plugin for your redirect purposes. For my needs, it was acceptable to use the Heroku application name for SSL requests only so I had something to work with.
I ended up making a minor tweak to the ssl plugin that forced a redirect to the Heroku application domain name when a secure request was called for and a redirect to my custom domain on the way out (note, I also forced all inbound requests to go to www.foo.com to ensure foo.com requests that end up requiring SSL played along nicely as well). Now, once you start hopping between domains, the Rails default of maintaining session in cookies becomes problematic, notably when utilizing Authlogic (as it stores the active user's credentials in session). In order work around this, opt to store your session using ActiveRecord. With the session in the database, you then have options. In a modest effort to try and not make this too hackish, I created a method that loaded a specific session from the database and then called this method via filters for the actions that required SSL. So in short, you end up with the following chain of events: 1) A secure request (with the session key passed as a parameter) is intercepted by the SSL plugin. 2) The request is rerouted over SSL to your Heroku application domain. 3) The before filter is executed prior to the action requiring SSL that rehydrates the session from the database on the Heroku application domain side. 4) The action proceeds as normal. 5) On the way out, it's business as usual, with the plugin rerouting back to your custom domain where the prior session still remains fully intact. Admittedly, it's a band aid until SNI becomes a more viable option and/ or another solution emerges with Amazon permitting multiple IPs to point to a single EC2 instance; for now however, this gets the job done. If this sounds like something you're interested in exploring further, I posted a more in depth write up a few weeks ago at http://www.chrisbaglieri.com/2010/01/01/heroku-hacks-ssl.html. Feel free to ping me directly if you wanted to chat about this further. Cheers, Chris On Jan 20, 1:40 am, Kenny Carruthers <[email protected]> wrote: > Hi, > > Had a quick question regarding the piggyback SSL implementation. We > have a very standard Rails application hosted on Heroku with a custom > domain. Users can log into our site and we're using Authlogic for > handling user login. > > Without using any SSL, the login works fine because the login form > simply posts the user's login credentials back to Heroku using our > custom domain name. > > However, when we enable the piggyback SSL, we obviously have to fall > back to posting the login form to our heroku.com subdomain. The user > login now fails because we're posting login credentials to our Heroku > subdomain via SSL (which the auth cookies are stored under), yet > redirecting the user post-login to a page back under our custom domain > (which doesn't have the auth cookies). > > If, post-login, we keep the user on our Heroku subdomain then > authentication continues to work as expected. So clearly the problem > is that the actual, SSL encrypted login is occurring under one domain, > but the subsequent redirect is occurring on our custom domain. Since > the original auth cookie is only under the Heroku subdomain, the user > is effectively not logged in for browsing using our custom domain. > > As much as we love Heroku, we'd ideally like to keep the custom domain > name the only one visible in the address bar. > > The only way I can see to work around this is to pass a perishable > token in a URL string as part of a redirect from the Heroku subdomain > to our custom domain, then set the cookie once we're back under our > custom domain. This effectively follows the model of how things would > work if the user did not have cookies enabled. > > I'm just wondering if people have any other ideas on how to get around > this. > > Thanks in advance for any comments or suggestions. > Kenny
-- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
