I'm implementing login and registration for multiple domains that talk to a single database - we'll call them i.domain-a.com and i.domain-b.com. Both these subdomains have A records in the DNS that point to a single server - thus making i.domain-a.com/hello.php and i.domain-b.com/hello.php run the same thing.
So, if I create a session on domain A, then I can go to domain B and retrieve the same session information. To implement completely separate login systems for both of them that utilise the same PHP functions I have written to handle registration, should I do something with session_name() based on $_SERVER['HTTP_HOST']? I'm not sure how similar my situation is to this guy, and hope this question isn't too similar.
To avoid problems with sessions you should use the session_name('myapplication') [ session_name({UNIQUE_APP_ID}) ].
The problem you are mentioning can occur in more simple situations where there is an administration panel and a sign-in form for the users of the web site.
If session_name is not used a signed-in user could have access to the admin. panel but this depends on the auth. scheme and mechanism you have implemented.
regards,
Sessions/cookies are domain-specific and don't rely on DNS settings. If you want both system's sessions to be separate while they live on separate domains you're already all set.
I believe session_name() would've actually been the best solution for that other guy's question, two separate sessions on the same domain.
No. The mechanism that stops different users getting the same session works on a per server basis, not a per hostname basis.
Related
There is any way to check the login status through different programming language?
Right now I'm using three session (same name) that starts at the same time after the login process, using ajax.
Right now, the login.html form is processed on three files: login.aspx, login.asp and login.php but it's seems too slow and weird. I'm combining three different services from the same company into one, after re-building the users and others common tables in mysql, everything seems to work fine, but I'm really scared about security bugs.
Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
This sounds like single sign-on to me. Let's try to split the problem.
There is any way to check the login status through different programming language?
You're not really interested in the language used. Any language, given the same info and algorithm, would decode with success the same encrypted data. I guess you're instead having problems because PHP's application logic regarding this point is different from the ASP's one.
So for the first point, you can
Implement / normalize the same session checking logic among all of your apps. This is probably unfeasible, because you might be using Laravel here, and ASP.Net on the other, and the two are probably slightly different in this regard. If you can, do this, or...
Look into JSON Web Tokens. I won't go into detail, but these were more or less designed to solve this class of problems. They are also easy to handle, but be aware, there are aspects you have to take care of when using them for user authentication.
[...] Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Not to be that guy, but some concepts are somewhat deformed here. Sessions don't expire on files; they normally are setup with a given expiration time and a given domain. So generally speaking, a session opened from a PHP app, and stored on a cookie, then read from an ASP one shouldn't change, given that no difference exists between the two app's session handling logic.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
For both of the solutions i suggested above is, especially for the cookie one, it's important you make the apps absolutely identical in respect to session handling. While this is trivial with JWT (as there's barely any logic on the app's side), this may prove to be harder with cookies if the authentication logic comes from some one else's code (as in a framework).
I haven't asked about single sign-out, and at this point i'm afraid to ask :). But these are some guidelines:
If going the cookie route, be aware of cookie's domain. A cookie is normally valid for every request coming from the website domain (name.com), but you may have some of your apps under a subdomain (like, phpapp.name.com). In this case, be sure the cookie created from the given app is valid for the whole domain, and not just the subdomain. And make the apps available at subdomains / pages under the same domain. Cookies don't work cross-domain, and you have to deal with that, since cookie domain policy is enforced at browser level.
Launching three AJAX calls means triggering three login procedures. I suppose all of these would terminate, at some point in the future, and all of those would be storing / rewriting the cookie. If the apps understand the same cookie, it's mandatory you open the login process on just one of them. This would store the cookie, which would then be automatically picked app from, say, a page in the second app, giving you a seamless transition into a logged-state in the second app.
JWT would normally require some JS work, which you may like since the same script can easily be loaded in all of your apps. On the other side, you can be sure that different server libraries handling JWT would all work the same for you, thus ensuring compatibility.
Personally, i would look into JSON Web Tokens.
You can develop your own session provider which stores data in a separate place (for ex. in database or files). Then everything you need to do is write some code in every environment to handle your session information from that provider. Because you use only one source to store session information there will be no problem with synchronization between any of yours environment.
If you need then you can use a webservice for exchange session information between every environment and session provider. Every application can use security connection to get and set information about session from that session webservice.
I think you can do this!You can create provider which stores data into database. Then Write some cool code to manage your provider.You can also use webapp or sevice.Every service use security to get and put information.
I had a scenario and want opinion by you people.
I have different web applications developed in Django, Rails, PHP , I want all of them to share the same session data every time. Means if a use is logged in to a PHP app, it can automatically be logged in to Rails app and vise versa.
I know its some kind of Central Authentication Server. Some of these are cas, josso.
What do you people have opinion for it. I want the behavior like Google Apps, when i am logged into Gmail, i can automatically logged into GoogleDocs as well.
Please share your thoughts, that how to implement this scenario?
Google runs entirely off the .google.com domain, which is why they have absolutely no problem using a single cookie to identify you across applications. If your applications all run on the same domain, I'd say go ahead and write a custom implementation to authorize users with a shared session cookie.
However, in the more likely event that this is not the case, you're better off implementing one of the more popular and wide-spread SSO methodologies like OAuth or OpenID seperately in your applications and either giving your users a centralized application at which to authenticate, or let them authenticate via external providers (like Facebook or Google, which supports authenticating via OpenID)
You can run your own OAuth or OpenID endpoint at which your users register and then auth via this endpoint on any of your applications.
In PHP, you can use session_set_save_handler to specify how the session is persistent and restored. I guess Django and Ruby On Rails provide similar means
just store the sessions in the db ore handle them yourself completely
the best approach would be to create a special table for this
watch out as php want to store this data sialized so unserialize before storing in the appropiate field as serialized data is too hard to handle
in php you have
$_SESSION
and session_set_save_handler()
but i think it is better for you to make it yourself
make sure all sites use a single cookie domain(ajax onload(to try getting this coockie), or keep the same domain)
In my apps I use SESSION to store a value of logged in user. For example $_SESSION['site1']['bakcend']['loggedin']=1; Than put a session check on other places. They of course are all under same domain.tld If you use above example $_SESSION['site1']['bakcend']['loggedin']=1; you will need a lot of checks if you have many sections. But this is only an opinion, there is a place for much more flexibility.
You can use cookies too.
I'm working in a website that is going to work like a landing point, providing a specialized service for many other websites. Users log-in to different sites and those sites have links to my website.
Now, I want to create my website using asp .net, and also I want to be able to use SSO (Single Sign-On) so the users doesn't have to authenticate again when they land on my site.
The problem is that most of the websites that are going to use the services of my site are in php, when users login on these sites, all the authentication process is handled and also a lot of data is fetched into the Session variable; what I want to do is to be able to capture all the data in the session variable coming from the php page, in my asp site.
I don't know if this is possible, maybe this can be done in another way
So far, the only thing I've been able to do in the asp is, ask for a parameter in the url and using that parameter query the database to get all the data that was already in the session in php.
So if any of you know a way to do this.
Thanks
My company does this extensively. Our app passes information from our software to other systems such as CRM's, appointment schedulers, data aggregators, etc. In cases where systems are radically different and access is not explicitly given, the best solution we've found is to use cURL and negotiate a data interchange via API. Setups with people of varying technical abilities can be challenging (we've actually provided code for several systems we wanted to communicate with) but in the end it's efficient and secure.
Unlike many UI guys, I'm a fan of OpenID for single login. However, that doesn't pass all the data you likely want to interchange between the sites.
You could either use a database as a session store point accessible by all pages. this makes it pretty easy to access session data by either php or asp.
I think this would be the mos performant way.
If you don'T want to give the other php sites any access to your databases you also could create a special page not for vewing in asp and tell the php sites to drop the session contents via curl there and in that sie then save the session stuff in your database.
It's not clear from your question whether you are hosting both ASP and PHP websites on one server or if your ASP site will be used with other third-party sites.
If you run and manage the ASP and PHP sites on one machine, then storing session information in the database will be the way to go and isn't too difficult. You'll need to make sure that the session data you store in the database can be read by both PHP and ASP--I'd pick something simple like JSON. A url parameter would be a bad way to get at this data, as it makes user information available to anyone who could guess a user id.
It's not so simple, however, if you want to provide SSO capabilities with third party sites. In this case, you'll have to implement an authentication API that the third party sites can call to log their user into your site when they initially authenticate the user on their own.
I have seen a few answers to this on SOF but most of these are concerned with the use of subdomains, of which none have worked for me. The common one being that the use of session.cookie_domain, which from my understanding will only work with subdomains.
I am interested in a solution that deals with deals with entirely different domains (and includes the possibility of subdomains). Unfortunately project deadlines being what they are, time is not on my side, so I turn to SOF's expertise and experience.
The current project brief is to be able to log into one site which currently only stores the user_id in the session and then be able to retrieve this value while on a different domain within the same server enviroment. Session data is being stored/retrieved from a database where the session id is the primary key.
I am hoping to find a "light wieght" and "easy" to implement solution.
The system is utlising an in-house Model View Controller design pattern, so all requests (including different domains) are run through a single bootstrap script. Using the domain name as a variable, this determines what context to display to the user.
One option that did look like to have potential is the use of a hidden image and using the alt tag to set the user id. My first impressions suggest this immediately seems "too easy" (if possible) and riddled with security flaws. Disscuss?
Another option which I considered is using the IP and User Agent for authentication but again I feel this not going to be a reliable option due to shared networks and changing IP addresses.
My third option (and preferred) which I considered and as yet not seen discussed is using htaccess to fool the user into thinking that they are on a different domain when infact apache is redirecting; something like
www.foo.com/index.php?domain=bar.com&controller=news/categoires/1
but displays to the user as
www.bar.com/news/categories/1
foo.com represents the "main site domain" which all requests are run through and bar.com is what the user thinks they are accessing. The controller request dictates the page and view being requested. Is this possible?
Are there other options? Pros/Cons?
Thanks in advance!!!
Have you thought about using session_set_save_handler. You can store your sessions in a database and access them from any domain.
Define a main session server (I do this in combination with memcached)
use Ajax / JSON(P) to request a session from this server, this allows you to share sessions over multiple domains
Reuse this session
For the benefit for anyone else interested in this functionality, there is no simple answer I am afraid. Google "Single Sign On" and it will come back with the technology and some solutions avialable.
As for using htaccess to hide the domain name, this is not possible as it could be used for malicious activities.
I have now successfully implemented a system to achive my requirements.
I need to share SSO information between two different domains with a cookie, can this be done in PHP and how?
On both domains, place an image or other web element that is pulled from the other domain. Use the URL to notify the other domain that user X is on domain A, and let domain B associate that user ID with that user on their system.
It's a little complex to carry out correctly, but if you think it through it'll work out very well.
Vinko points out in a comment (thanks!) that I shouldn't take it for granted that you understand the security risks involved. If this information is of any value to anyone, then you should make sure you use proper encryption, authentication, etc to avoid releasing sensitive information and to avoid various attacks (replay, man in the middle, etc). This shouldn't be too onerous since you control both websites and you can select a secure secret key for both, since the communication is only going between the two servers via this special URL. Keep it in mind though.
-Adam
You don't, cookies are bound to a domain. There are restrictions on this and it's referred to as cross site scripting.
Now, for some help to your problem.
What you can do is create a script that helps bridge them.
You can globally rewrite all links to your second site are going to need cookie information from the first site.
You would save all the cookies from site-a to a database that they both can read, then programatically appending the cookie-id querystring on all of the links to site-b, then you lookup that cookie id and re-set the cookies under the new domain.
There is a really good PHP database abstraction library (PHP ADODB) and it has a session sharing plugin that makes all of this a whole lot easier.
I'm not sure about the security implications, but there is an Apache setting that allows you to change the domain of a cookie.
# in httpd.conf (or equivalent)
php_value session.cookie_domain mydomain.com
I have successfuly employed this method for subdomains, but have never attempted for different domains.
There is also a method to set the variables direction in PHP described at http://us.php.net/manual/en/function.session-set-cookie-params.php. The documentation makes no reference to the ability or inability to set cookies on a different domain.
There is a different Stack Overflow thread on this same topic, but I don't think it was ever sufficiently answered.
Well, if your domains are just different subdomains you could do it in an easy way by creating a .yourdomain.com cookie. Then the cookie is passed along with all the requests across all the subdomains.
It's not that simple if you want to share cookies between different domains as browsers treat it as a security risk.
What is the exact example?
In case of some software like Google Analytics and other tracking images, etc. you might be forced to use P3P headers to let browser know you don't care about security when sending your cookies. Then a browser requesting image gets a cookie as part of the response and also inspects P3P. If all is OK it saves the cookie on the hard drive and the next time you request an image that sits on your website (but is part of other domains page) the browser will send the cookie along. But I guess this does not help ;-)
I have never used a cookie value across domains in a direct meaning of it.
If you have two sites using the same domain and would like to share cookies between them, set something like this in your settings.php file for each domain:
ini_set('session.cookie_domain', '.EXAMPLE.com');
Be sure you include the leading '.' before the domain name, or it won't work.
This allows users to maintain login status between any sites configured for domain-wide cookies.
This can also have negative side effects, so don't do this unless you're familiar with all the cookies involved for the sites you want to share cookies between.