small medium large xlarge

Monki100_pragsmall
25 Feb 2008, 16:42
geemus@gmail.com (4 posts)

I’ve tried a number of different combinations of setting options to try and get recipe 65 working, with no luck. I’m trying with CookieStore again at present, but tried with activerecordstore as well and had no better luck.

As soon as I set the session_domain, for instance by following the example in the recipe, to: ActionController::Base.session_options[:session_domain] = ‘.example.com’

Then sessions are no longer persisted, at all. It doesn’t store any cookie for the session at all and you get a new session with every request. If I remove it sessions work again, but then of course I get separate sessions for each subdomain. I am on edge rails (updated as of this morning).

Any help would be greatly appreciated as its driving me quite mad.

Mike-120_pragsmall
26 Feb 2008, 15:10
Mike Clark (51 posts)

Just wanted you to know that I’m looking into this and will get back to you. It was last tested on Rails 2.0.x, but not on edge Rails. Nevertheless, we certainly don’t want a recipe that doesn’t work. :-)

Monki100_pragsmall
26 Feb 2008, 18:29
geemus@gmail.com (4 posts)

Certainly. I may well have mucked up some settings some where too, but I had tried any number of variations/alternatives with no real difference. I’d be more than happy to provide any other info you might need to replicate the problem, and I look forward to actually knowing I’m not just crazy :)

Monki100_pragsmall
27 Feb 2008, 07:29
geemus@gmail.com (4 posts)

Figured it out. It works fine as long as you don’t try to set the session_domain to something related to localhost. I ended up using ‘.mydomain.dev’ and adding the entries to the host for development and ‘.mydomain.com’ for production and it works as expected. So, perhaps a note to avoid localhost would be in order.

Mike-120_pragsmall
27 Feb 2008, 19:06
Mike Clark (51 posts)

Thanks for the update. I’ll add a note. Can you clarify what you tried that did not work?

Generic-user-small
29 Feb 2008, 10:05
Morten Christensen (4 posts)

I have the same problem. Giving users a custom SUB-domain works but I can’t get the fully custom domain feature to work. No sessions are started so it appears to be a cookie problem. I have tried not using localhost as the reader on this thread suggests but to no avail.

Besides I have a number of issues with this recipe. 1) It is unclear what to do with “ActionController::Base.session_options[:session_domain]” to support both custom SUB-domains and fully customized domains. First he states to use it for SUB-domains and then not to use it for domains. What do do when using both ?

2) What exactly does this mean at the end “It’s also not wise to allow people to register domains under the main name of your app.”…. Does this mean that the custom subdomain feature is not really something that is adviced after all?

3) There are problems with this recipe and SSL. As far as I can see the fully custom domain feature that the author writes about would never be fully usable with any single SSL certificate so forget about using this feature for a secure site….My current thinking is that a controlled redirect from the custom domain to the custom SUB-domain + a SLL wildcard would be the only think that would actually work for a secure site (this is also how google apps works)…. Am I wrong?

Sincerely, Morten Christensen

Monki100_pragsmall
29 Feb 2008, 19:38
geemus@gmail.com (4 posts)

Mike:

I tried a couple different things in my hosts file.

I tried just using ‘localhost’, ‘subdomain.localhost’, ‘test.localhost’ and had no luck. Then thinking that perhaps it was an issue of lacking a tld I tried ‘localhost.host’, ‘subdomain.localhost.host’ and ‘test.localhost.host’.

I’m not sure where things get off in this configuration, but none of those variations ended up working.

When I changed things around to use ‘domain.dev’, ‘subdomain.domain.dev’ and ‘test.domain.dev’ things worked properly. I suppose you might or might not need to flush your dns cache if you are making a lot of changes to this stuff, but it shouldn’t need it when you first define them.

Hope that clears it up.

Morten:

1) I haven’t done anything with multiple fully customized domains. You can use the session_domain setting still, but it will make the same cookie be in effect across all the domains. Just depends what you want it to act like whether or not you should do this.

2) I believe he just means its a bad idea to let somebody register to use ‘domain.domain.com’, like letting somebody use ‘google.google.com’ or something. It doesn’t break anything, but it could be confusing for users as they would likely think that this was an ‘official’ page, rather than that of a particular user.

3) I think you are on the right track there. Have the ssl for your main domain and make them login through this, but have all the subdomains reference the same cookie to see if you are logged in. I’m not using ssl, but I am expecting users to sign in through the main domain rather than a subdomain.

Mike-120_pragsmall
29 Feb 2008, 21:46
Mike Clark (51 posts)

Morten kindly tested out a few changes to the recipe, and it seems to be working much better now. A revised version of this recipe will appear in the next beta release. In the meantime, to get this to work with cookie-based sessions and AR sessions in Rails 2, use:

def set_cookie_domain(domain) cookies = session.instance_eval(“@dbprot”) unless cookies.blank? cookies.each do |cookie| options = cookie.instance_eval(“@cookie_options”) options[“domain”] = domain unless options.blank? end end end

Generic-user-small
19 Apr 2008, 14:19
Sebastien Lamy (2 posts)

Hi, I saw a message related to this topic “here”:http://szeryf.wordpress.com/2008/01/21/cookie-handling-in-multi-domain-applications-in-ruby-on-rails/ I tried this recipe but it didn’t work for me (I don’t know if it camed from the fact my main host was localhost at the moment testing this recipe).

The trick given on the post I link to worked for me, but only for domain with a dot inside (eg:not for localhost). I just aliased localhost.fr in /etc/host, and everything worked fine for development.

You must be logged in to comment