I am working on a site that has a login API. So when people login on my site, they will automatically be logged in to other sites.
Is their way by which a session can be setup so that other websites can use it? If not, is their any other solution?
One way - you can store your session values in database, and can use in other sites. :)
Example:-
let suppose if my site is deployed on multiple servers and end user might be redirected to different servers accordingly to traffic, then it would be good to save the session values in db.
Yes. It's possible using in example Redis for the session storage. You should look for configuring php sessions to use custom storage. Here is php man for this http://php.net/session.customhandler
What you want to do is probably using a cookie that is spread over your whole domain. This cookie can then be linked to a session. I'm currently working on something like this on Symfony2.
As example:
login.mydomain.com
application.mydomain.com
etc.mydomain.com
login.* will obviously contain my login logic + forms etc. This will also contain an API which the other applications can verify the cookie to. My Application will first check if the user is logged in. If not, it will check if it has the required cookie. If it does not, it will redirect to the login.* login page.
If it does have the cookie, it will validate this in my login.* API. Expired > redirect to the login page, if not it will return the required info of that user and "login" to my application.
The only problem I have at the moment is storing the session. I use mcrypt to encrypt the contents and store it in mysql (cookie_id, cookie_contents). I have but 1 problem, it doesn't automatically purge the expired sessions, I still have to find a solution for this.
What you are basically looking for is Single Sign-On (just a guess, but I think accurate).
Related
I'm new to PHP, I read other articles without finding the answer I'm looking for, but still don't know if what I want to do makes sense or not.
I'm using PHP 7.
My user authentication page, checks credentials and then executes session_start(), creating the session server-side and a cookie client-side in the browser.
Each other page of the web application then calls session_start() to resume session information, in this case checking the cookie. Everything works fine so far... at least when I have a single login.
I'd like to be able to have more than one user SIMULTANEOUSLY logged in the same browser (on another tab for example.) using cookie. I don't want to append the session ID to the URL.
I managed to create different session on the server-side using session_id() before session_start() in the authentication page based on username, but the problem is on the client side.
The first successful login (session_start()) creates a cookie and the second login updates the same cookie corrupting the previously created session.
Therefore when it comes to resume the session, session_start() will resume only the last session, mixing the data fetched from DB based on session info.
Is there a way to make session_start() create a cookie for each login and make PHP resume the correct session using cookies?
Any ideas?
FURTHER DETAILS:
I'm updating a legacy app trying to fix some security issue. The need for multiple sessions comes from administrative purposeses where admins access the same site. The reason why it's needed a separation of session is that depending of the session info, the data are fetched from a different database. Therefore, a regular usage would only need one session per user, but the administrator he needs to make multiple logins viewing different data depending on that login.
The default PHP behaviour is to handle sessions using cookies.
..and the default behaviour for browsers is to "reuse" the same set of cookies if you revisit an URL in another tab.. So, like mentioned below:
The simple way probably is to start another browser. Not the same browser but like firefox and chrome, if you have multiple browsers installed.
Another way would be to install a browser plugin, like Sessionbox for Chrome or Multifox for Firefox.
Edit, for clarity: I can think of two cases when multiple sessions would be used:
During development. Depends on the application, but an obvious case would be testing communication between two users.
After deployment. Though I've never seen a site that required multiple logins for the same user account.
This is my frame of reference. Based on this I assumed the question was for development. I'm not suggesting that the site should require installing extra packages. Flash would be about the only one that's ever gotten away with that..
You can use the same session but change the variable names that you are looking for:
if ( $_SERVER['REQUEST_URI'] == '/admin/' ):
$session_name = 'session1';
else:
$session_name = 'session2';
endif;
session_start( $session_name );
We are currently using a custom login system that sets a hash in the database on one site, and then when the user transfers between domain and sub-domains it logs them in. It doesn't always log the user in so they click on on the login link/button and it takes them to the login and if they have a session it loads it otherwise it shows the login page.
We would like to get away from that and use something better. With php there is session_set_cookie_params and we were wondering is this secure?
session_set_cookie_params(3600, "/", ".example.com");
If this isn't a good way to use a session across multiple domains what is a better one?
We also have a few subdomains that use their own login system where the same user has a different username/password on that system, will this/that be a problem? We feel that it could be possible that two different people could have the same session id logging two different people on to the same account, since they manage their own sessions.
It is a fine approach, however you have to consider that, if all domains/subdomains you want involved in the same session are not on same server or reside within different applications, that you need to provide some common backend session-storage mechanism that all applications can access for session data.
As far as dealing with multiple logins, you would likely need a logical way to link the logins together so that you can understand that a valid session under one login could be transferred to another login on a different domain. This is really your largest security concern, and one that should likely be addressed by implementing a single sign-in mechanism.
Normally When I design a site that allow users to login, I create session variables of the user info from the database and ensure that at least one of the session variable is available on each page of the site, else the user would be redirected to the login page like this:
if(!isset($_SESSION['username']))
{
header("Location:login.php");
}
But then I've been thinking lately, instead of using session variables to authenticate users, why not use the query string. My idea is to create a unique string which is based on some factors, like date(month, year, day) or access time(day, hour) or ip address, and maybe hash it using md5 so the url might look like this
://mysite.com/dashboard?auth=12jsdnnau819wiskj3jdnck23ksj12j3.
So now I can easily logout a user if he has not accessed the site for more than one hour or more than one day. But I do not know if this is a good idea, that is why i am here, to seek for advice on a better way to go. Thanks all.
Because URLs:
Leak easily
Get bookmarked
Don't carry their data over automatically when the user opens a new tab and navigates back to the site
and because nothing is stopping you from storing the same data in a session and using that to easily logout a user so it doesn't even add the one benefit you highlight.
Don't do this.
Do you remember the days when PHP session ID could be stored in the URL, and you would have URLs that look like: index.php?PHPSESSID=.... ?
We have moved away from this to more secure implementations, user friendly URLs, etc.
Just as a simple example of what can go wrong: A web crawler can crawl your website, and if reaching the admin panel with a properly authenticated URL (as you described), it could become publicly available to ... anyone.
So ... don't reinvent the wheel.
I can think of a few reasons not to do this:
The hashed request parameter is publicly visible. This means anyone using that url will be considered an authenticated user.
As I can see, the token is per user, so all requests using this token will be done on behalf the same user. If you share a url, anyone using that url will impersonate the same user, and have all the access rights granted to that user.
Other answers have mentioned that the urls can easly leak, or be bookmarked. In addition to their points, once the token expires, the url may become broken, if you trigger a login or other authentication redirect mechanism.
A pure technical drawback of your idea is also this: you need to persist the token when navigating across different pages in your app
The HTTP Session has been designed to serve this purpose and at the same time be safe enough. The application session length can be tuned so that it matches your requirement. I recommend you to get familiar on how HTTP sessions work and how to tune your session expiration policy, rather than compromise your application's security
I want to implement a "remember me" feature on a website I am currently working on, so that when a user closes the browser and open it again, he will still be logged in with the same user.
What i currently have is a log in page that creates a session when the user logs in. What I want to do is to create a cookie that saves information about the user that allows me to identify him.
Now there are a few thing that I need your help about:
I don't want to save any sensitive information in the cookie, such as passwords or even a username. What i though to save is the session ID created when he first logged in, and save it in a table on MySQL database. Is that a good idea, or is there something better that i can save on the cookie?
After I implement the "remember me" feature, will I still need to use sessions? What I mean is, that the website have the option to use it without a user, so of course on every page of the website I will have to check if the user have a cookie stored. If he does I will automatically log him in, but should I do it using a session? isn't it a duplicate that I use both cookies and session for the same purpose, and of course do it for every single page of the website.
By the way I am developing the website using PHP.
It doesn't really matter. Only I would refrain from reusing this value as a session id again.
Yes, you will still need sessions, unless your site is extremely simple.
You can store the md5 of the cookie in the database...but just remember. If a user has multiple devices you get a cookie for each device.
If you don't clean your table once in a while it's going to contain lots of data!
I currently have a website that allows my visitors to login via a simple script i've pasted together and wrote. Currently I only use sessions to keep visitors logged in. Are there any advantages to adding cookies to my website to store user logged in status?
Or is there a better way altogether?
using PHP
If you are using PHP sessions then you are using cookies. PHP stores session ID in cookies and the session data to a file on the disk on your web server.
#Ramiro Gonzalez Maciel he said he has made that script, he doesn't need frameworks to take as examples. Frameworks usually have scripts wrapped up and well placed.
To respond that question:
I usually store in cookie some md5 strings that are combined from his md5(password) and his username so I'll know next tim he enters my website that is was logged in so I wouldn't make him login again
my example:
<?php
$username = $_POST['username'];
$password = $_POST['password'];
// sql and escape stuff witch will return 1 if he has entered a valid login
if($sqlreturn == 1){
// do login
$wraplogin = md5($username."-".md5($password)."-".SECRET_KEY); // I always define a define('SECRET_KEY', 'mysecretkey'); in global file.
// now you can store that $wraplogin in cookies and remember his login. Next time he enters the website, you read that cookie, compare it with what you have in your database and let him in.
}
?>
Now I know that is not the best example, but I've personally used it in very large websites (>500.000 users) and none has hacked in yet :)
That's the advantage in cookies for the login part.
Best of luck.
The web frameworks ( Java Servlets and others ) usually use cookies to identify sessions; the other usual option is URL parameters. So assuming you're using any web framework, it's probably already using cookies to store the session id. The Web Framework will use this ID to identify the Session object in every request. Although cookies survive server restarts, since they're stored in the browser, Session objects usually don't unless you've configured Session persistence.
If you want to users to "auto login" as in the usual "rembember me" option many web sites implement, you would have to persist Session objects if your framework provides that. Or implement a similar system, using cookies to store a "logged in token", and checking that token when the user access the system to auto-log them or send them to a login page. ( Edit: like Mihai proposes in other answer )
If you want to implement your own method, I suggest checking how the popular web frameworks implement this, specially the security and privacy aspects of storing user data in cookies.