Hi, there are a lot of rails application out there that permit the users to host the application on a subdomain (e.g. http://test.myapp.com) or over a user external domain (e.g. http://testapp.com). How this is managed this in the code? I''m googling around but finding only about subdomains, not external domains. Also, how can the sessions be managed? I mean, a user login on an https page on myapp.com and then redirected back to testapp.com, will the session be kept? Otherwise, how can this be solved? I''d like to manage all this automatically, without having to set a vhost for every application/domain and all the links on testapp.com should be referring to testapp.com, not myapp.com Thank you -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 23 Nov 2010, at 23:39, Xdmx Xdmx wrote:> Hi, there are a lot of rails application out there that permit the > users > to host the application on a subdomain (e.g. http://test.myapp.com) or > over a user external domain (e.g. http://testapp.com). > > How this is managed this in the code? I''m googling around but finding > only about subdomains, not external domains.Much in the same way you handle subdomains, but with the complete domain as a value in your database instead of just the subdomain.> Also, how can the sessions be managed? I mean, a user login on an > https > page on myapp.com and then redirected back to testapp.com, will the > session be kept? Otherwise, how can this be solved?This is more complicated. You need to do it in a similar way as omniAuth does for Twitter/Facebook/OpenID/… logins.> I''d like to manage all this automatically, without having to set a > vhost > for every application/domain and all the links on testapp.com should > be > referring to testapp.com, not myapp.comYou should automate it then. You will basically write to the Apache vhost conf files (and possibly the dns server configs) and reload the configuration from your Rails app. The main concern here should be handling the security on the system level. As long as the user then goes to the full domain, all links will stay within that domain. Best regards Peter De Berdt -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi Peter, thank you for the reply> Much in the same way you handle subdomains, but with the complete > domain as a value in your database instead of just the subdomain.mmm..ok, i''ll try it out, considering that i''ll have to manage both domains and external domains> This is more complicated. You need to do it in a similar way as > omniAuth does for Twitter/Facebook/OpenID/ logins.could you please explain better this part? or if you have some docs/posts i can read about> You should automate it then. You will basically write to the Apache > vhost conf files (and possibly the dns server configs) and reload the > configuration from your Rails app. The main concern here should be > handling the security on the system level. As long as the user then > goes to the full domain, all links will stay within that domain.what about an approach like set a dedicated ip for the app, and in the apache config accept all the requests to that ip and be managed by the rails app. In that way the user could simply change the A record of his domain and it should kinda work (i''ve not tried it yet, but iirc in the apache config is possible to do something like this... i don''t know with nginx though) Thanks -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 24 Nov 2010, at 13:07, Xdmx Xdmx wrote:>> This is more complicated. You need to do it in a similar way as >> omniAuth does for Twitter/Facebook/OpenID/ logins. > > could you please explain better this part? or if you have some > docs/posts i can read abouthttp://www.windley.com/archives/2006/04/how_does_openid.shtml http://en.wikipedia.org/wiki/OpenID Basically you post the login credentials to your second app through URL +POST parameters, your second app authenticates and sends back the data needed to identify the user, first app uses this to create the session. This is extremely simplified and you''ll need to worry about security, establishing trust between the apps etc. Another way to go about it is to use ActiveResource, which basically establishes interapp communication on a server level. It all depends on your needs basically. Don''t try to overcomplicate matters too much by trying to decentralize too much (decentralization has its uses and advantages, but it also brings a whole slew of extra work).>> You should automate it then. You will basically write to the Apache >> vhost conf files (and possibly the dns server configs) and reload the >> configuration from your Rails app. The main concern here should be >> handling the security on the system level. As long as the user then >> goes to the full domain, all links will stay within that domain. > > what about an approach like set a dedicated ip for the app, and in the > apache config accept all the requests to that ip and be managed by the > rails app. In that way the user could simply change the A record of > his > domain and it should kinda work (i''ve not tried it yet, but iirc in > the > apache config is possible to do something like this... i don''t know > with > nginx though)Could also work. Best regards Peter De Berdt -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> http://www.windley.com/archives/2006/04/how_does_openid.shtml > http://en.wikipedia.org/wiki/OpenID > > Basically you post the login credentials to your second app through URL > +POST parameters, your second app authenticates and sends back the > data needed to identify the user, first app uses this to create the > session. This is extremely simplified and you''ll need to worry about > security, establishing trust between the apps etc. > > Another way to go about it is to use ActiveResource, which basically > establishes interapp communication on a server level. > > It all depends on your needs basically. Don''t try to overcomplicate > matters too much by trying to decentralize too much (decentralization > has its uses and advantages, but it also brings a whole slew of extra > work).Mmm.. but in this case you''re considering that there are two separated applications, but actually there is only one application which manage both the main and the external apps/domains. The signin/signup page will be on the main address (in order to have a correct ssl from the main domain), but then the user will be redirected back to the external domain. This shouldn''t be a big problem, my worry is about the session cookie, having it set on the main domain it would refer to it, and it actually won''t be in the external one. Otherwise to solve it the signup/signin page could be on the external domain too, but without a ssl page it wouldn''t be so cool (actually it would be better on everypage, but i''m worried that it would overcomplicate a lot all the system) -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 24 Nov 2010, at 15:58, Xdmx Xdmx wrote:> Mmm.. but in this case you''re considering that there are two separated > applications, but actually there is only one application which manage > both the main and the external apps/domains. > > The signin/signup page will be on the main address (in order to have a > correct ssl from the main domain), but then the user will be > redirected > back to the external domain. This shouldn''t be a big problem, my worry > is about the session cookie, having it set on the main domain it would > refer to it, and it actually won''t be in the external one. Otherwise > to > solve it the signup/signin page could be on the external domain too, > but > without a ssl page it wouldn''t be so cool (actually it would be better > on everypage, but i''m worried that it would overcomplicate a lot all > the > system)The simple fact of the matter is that sessions can only be created on the domain in the url (subdomains can share a session, but the domain is still the same). In your case, if a secure page to login is a requirement and you don''t want to buy a certificate for every single domain that registers your app, you will have to use some form of interdomain communication to authenticate the session in the external domain. It doesn''t matter if the authentication is actually in the same app or a separate one. The domain is the unique identifier here, not the app itself. (And SSL certificates shouldn''t be implemented for coolness, but I get your point ;-)) I have quite a bit of other stuff on my mind right now, but something like this comes to mind: - Browse to external domain http://external.domain.com/ - No session => redirect to main domain login page (passing in the originating domain as a parameter) https://maindomain.com/login?domain=external.domain.com - User enters login data, your app verifies the credentials and writes an expiring token (a few seconds should be enough) to the user table for the user logging in and then redirects to http://external.domain.com/login?token=af8117c03b3f01b20b9360f2fb5fee57 - Your external domain will be able to verify which user it''s about and build the session on the external domain. It''s very important here that the token you use expires fairly quickly so sessions can''t be hijacked. Maybe some people will read this and raise some security concerns that I haven''t thought of, but as I said, I''m just saying what comes to mind without thinking much further :-) Best regards Peter De Berdt -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 24 Nov 2010, at 16:29, Peter De Berdt wrote:> - User enters login data, your app verifies the credentials and > writes an expiring token (a few seconds should be enough) to the > user table for the user logging in and then redirects to http://external.domain.com/login?token=af8117c03b3f01b20b9360f2fb5fee57 > - Your external domain will be able to verify which user it''s about > and build the session on the external domain. > It''s very important here that the token you use expires fairly > quickly so sessions can''t be hijacked.Or you can even delete the token when your external domain verifies the user token. This is all assuming all domains use the same app and thus database of course. Best regards Peter De Berdt -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Peter De Berdt wrote in post #963598:> Or you can even delete the token when your external domain verifies > the user token. > > This is all assuming all domains use the same app and thus database of > course.Hi Peter, the last solutions seems the best one imho... i''ll look better into it Unfortunately i''m from the old school where every login page should be on a ssl page.... and with firesheep around it would be better on every page, but that would be very complicated in this case. In the current app i''ll think if it''s so important to have the ssl or if i can get the auth using other methods (ie. fb connect/openid/etc), but for another big app there will be problems as it will need it and it would be better full ssl protected, but i don''t think it would be fully possible... :( Thanks for your hints! -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.