Fogbugz-on-demand, 37 signals, and PB-Wiki all use sub-domains with custom url's for each group of users to access their login page. So it doesn't even seem possible for a user using those services to login to a generc login (that any user of the service could log into.)
At first I thought this was a terrible design flaw, but now I think this is a really good idea because of:
1) Additional security, it may not be much, but you now need 3 pieces of info: 1 sub-domain url, 2 login, 3 password
2) You can let the same login log into different accounts by the subdomain url.
3) This lends itself to more isolation, load balancing, and easy deployment since you can have the subdomains running under different servers in more isolation from each other.
4) You can gradually roll out changes to a certain set of sub-domains that are marked as BETA users before deploying them to all users.
Are sub-domain based logins for web applications the future? Are there pitfalls with this design approach I'm not seeing? Is it too confusing for non-programmer users to understand the sub-domain concept?
We went with a triple-element login instead. We ask for the username, password, and client-id. Same concept as the sub domains but there's a common login URL. That works fine too. However, I do see an advantage in the sub-domain process, you can brand the login page because you know the requested client. In our approach we can't brand the login page since we don't know the client until you submit the login page.
Related
I have setup cloudflare for my prestashop website. In backend each time i refresh a page it points me to backend login page, it logges me out.
In customer account this behavior does not happen. If i login as a customer it works fine.
I have created a rule in cloudflare settings with url pattern matching my backend: example.com/admin123/*. No results, same behavior.
Do you have something to restore the visitor IP?
Generally see this kind of behavior if you're restricting logins to particular IPs and/or the CMS relies on unique IPs to login.
Can someone please help me to find a solution to maintaining the session across subdomains.
The site uses fake subdomains for users, eg. (thisuser.mysite.com/). All the fake subdomains map to the main site (mysite.com) so there's a common database for everything.
The subdomains are used only for a couple of components(com_xxx) on the site. for other components the user is redirected to the main site via htaaccess.
The problem is when a user is redirected to mysite.com from thisuser.mysite.com and vice versa. Their session is not maintained. The user has to login back again.
I have tried updating the cookie domain in php.ini to '.mysite.com' but it doesnt seem to help.
Is it possible that the site may have auto-logins across all subdomains and main domain without any core hacks, assuming the solution lies in making cookies readable from all subdomains, irrespective of from where it's being set?
Thanks all, for your time and suggestions !
I'm not sure how you could do this....
Here is just an idea, it would rely on javascript...
WHen a user logs in using your login form... a hidden iframe would exist and javascript would post your login data to the login page of each domaine for your site. chaining them...
i dont feel its a safe thing tho... maybe im wrong...
u could use joomla's mootool framework to send an ajax requests to each domain...
Otherwise might want to check how joomla creates a session row in the database for each user on the site. maybe you can just create them for each domaine with 1 login. im gona check my mysql....
are you using joomla 1.5 or 2.5 ?
Otherwise i found this document for you:
http://docs.joomla.org/Multiple_Domains_and_Web_Sites_in_a_single_Joomla!_installation
okay, this was easy, I was testing on the local machine and it seems if domain doesnt have the dot, then the cookies are not handled well.
Just ensuring taht cookie domain is set to '.mysite.com' gets the job done
1. It is also recommended that you use the same joomla "secret" configuration value in the different websites as it is used to check the data exchanged between the different domains.
2. taht cookie domain is set to '.mysite.com' gets the job done
For example: Once a user logged in, server side then needs to route the http traffics to a certain tomcat instance because all his/her files(not in DBMS but in local HD) stored on that machine and there will be interactions between the web app and underlying FS. Anyway to do this?
Thanks!
This is often done by redirecting to a server specific URL at or following login. The users session then continues with that URL. I frequently find www replaced with www1, www2, etc, after login on sites I use.
I think I'm missing a very obvious solution here, but I'll ask anyway. I've got a grails application that uses the Spring Security Plugin for my AAS. I want to start doing daily build and deploys of the application using Hudson onto a test server (running Apache2/Tomcat6) as the ROOT application. When the application goes live, anonymous users will be able to access the site, along with registered users. However, during the testing/development phase I want to restrict users to those who have been invited.
I've created logic to generate an invitation code, and a temporary "login / registration on invite" view to be used during this dev/test phase. Currently I'm using a filter to redirect any non-logged in users to that view. The problem is the filter is catching any request, so any additional applications (IE Bugzilla), URL's that would normally invoke a 404, etc are also being filtered, and the user is redirected to that same login page, even if they are already authenticated.
I had opted to go the filter route, instead of modifications to Spring Security settings, since this process is only a temporary solution, and I feel it will be much easier to remove at a later date. Is this a good Idea or is really not worth the hassle? What is the proper way to force only users of the application to log-in, but ignore requests to other URLs?
The problem doesn't seem to be in your web-app, hence not in Spring Security. It is probably in the Tomcat or Apache settings. If set up correctly, the request to other context path should never have hit your ROOT web-app in the first place.
Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life