I am working on an android app that is actually gets user data from android device and then to put it on the server, like to get user name, password, email for registration purpose and then user login to access the app menu (to see list of products, search for products and to add his/her own product details in the list). So using cookies and sessions would be a good idea for my app. Cookies can be blocked by the user and sessions every time to login to access.
But as i am totally new to this concept of cookies and sessions so it would be good to ask a question here before i have to start, that which one should i use cookies or sessions ?
The user can not block cookies. Cookies are simply headers that you will send in each request.
Cookies are easier to handle on the server side. You will simply use $_SESSION["variable"] to get/set any variable for the user. It will simplify your life on the server. However, I think the main drawback will be maintainability and administration of sessions. For example, if a user logs in again on a different device and you want the first session to be invalidated. It is not very straight forward.
If you want to use sessions, you will probably save them in a table on some database. You will need to fetch the session details when you need them. This is sort of extra effort. Yet, database sessions provide some kind of administration capabilities straight away.
I prefer database sessions for what is stated above and some other reasons. However it is up to you
Related
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).
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'm in the initial stage of building a php/mysql backend that exposes a REST interface to a website and iphone/android/etc devices.
I'm not quite sure what is the 'standard' or 'best practices' for dealing with sessions for multiple devices that use the same account.
Here is my current thoughts on how this would work:
I would use MySQL to store sessions for now, with a sessions table like so:
id, session_id (hash), user_id (int), created (timestamp), expire (timestamp), device (enum)
When a user login via iOS app or android app, I would return a session token in the success json for future api calls to use. Same with the website making an api call.
For security purposes, I should regenerate and overwrite the session token if the user re-login, but only for the session_id for that device.
I also have an expire column that tells me the expiration of the session so that if I wish, I can create a session that can expire in two weeks and is periodically cleaned by a CRON job.
This seem like a reasonable approach to me, but there are problems if the user uses an iphone and an ipad, or multiple android devices using the same account. Anytime the user logins with one would cause the other to log out.
I noticed instagram didn't invalidate the session even if I login from another iphone.
However, I don't think I can duplicate that behavior unless I never overwrite a session token when a user re-login or keep adding session rows into my session table whenever the user logins from the iphone?
What is the standard way of handling sessions across different devices?
I would highly discourage you from using mysql to store sessions. I would suggest using redis or memcache. Redis will store the data to disk in case your server crashes. Redis also allows you to set a TTL to expire the session, which would solve #4.
If you are using rest based calls, I would suggest just adding the session to the header as a cookie and pass that back and forth. Basically emulating the way a browser would access that page. I think that would make testing easier too.
Well it seems what you are looking for is not what most would traditionally call "sessions", which is something typically limited to a single browser or client instance.
It seems you are talking more about attaching application state to the user login. In which case, I don't see why you would have a need for a separate session table/token system. You would simply use your typical client-side methods of persisting a login, and then when that logged in client contacts your API, you would return application "session" state information, regardless of what actual client instance you are talking to.
This is not to say you wouldn't want to use some sort of token exchange system to give users "fresh" tokens in a case that you wanted to purge their state after a certain period of inactivity, just that you could have multiple active tokens per login.
I'm currently building a shopping cart for an eCommerce site and am wondering about the best way to persist user data in the session during the checkout process.
The user flow works is as follows:
shopping cart -> login/register -> select delivery address -> confirm -> pay
My issue is once a user is logged in, I want to display a list of their delivery addresses so they can select one. The easiest way to do this is querying the model by the user's id, but my concern is for security - my first thought was to store the user id in the session and then use this to retrieve the addresses. However there's nothing to stop another user potentially hijacking this id (just by guessing random numbers) and revealing addresses for other users. I could perhaps use their email address, but this too could potentially be guessed. Is my best bet to use a combination of the two, or is there a better way?
PHP has built-in session capability. It loads a unique cookie to the browser and allows you to keep all session data on the server-side via the $_SESSION array. The cookie ID is unique for the session, not the user, so it changes each time the user signs in (if the cookie has expired). If you conduct the session in https, it's very secure. Without https, the session is vulnerable to someone with the (special) knowledge and inclination to intercept the cookie data, though such an interception is not easy. Depending on how secure you want to be, running without https may or may not be acceptable for you.
You can read more about PHP session capability here:
http://php.net/manual/en/features.sessions.php
I have developed a web application in PHP for a client. The client is now renting out access to the system to another company on a per user basis.
Is there a way to prevent the secondary company to use a single login and give it to 20 people to use at the same time? I know one can get the IP address of the client machine that is being logged in from, but this is obviously not very reliable method. The answer probably lies in a combination of cookies and tracking things in a database, but my brain gets a bit stuck thinking on how to implement a strategy here.
Create a unique session ID when a user logs in and store that in the DB. Add something to the session authentication code (run on all page visits) that checks that the user's session ID is equal to the one in the DB and if not, log them out. Then your web app will be accessible by only one user at a time.
To be completely honest though, can't you raise this issue with your client?
No way to tell if the login is shared among 20 people. You can restrict access by blocking simultaneous usage thru session cookies.
Most of all, protect yourself with a published Terms and Conditions document. Violation of which - revokes any standing agreement/contract. And sue them if you can provide evidence (logs) that they violated it.
Make sure you bind one user to one session. In that way you can generate a warning screen if somebody uses the same login with another session. You can then let the user choose to close the other session.
In that way you can make sure two users are not using the system at the same time. It's a bit like a software program you have installed on a computer: multiple users can use it, but only one at a time. This is probably fine.
If you don't want that, you should try to bind the login more firmly to the user: make sure he logs in with a personal e-mail address, and he gets notifications (if applicable) via e-mail. Also let the user set personal configurations. In that way you create extra value for users to have their own account.
If you have a login you have authentication, and you write any user id in session, make sure that only one session with this id created, if the session already exists throw error message.
The only problem you will have in case and user did not logout properly, instead of it pressing x button on browser then he will not be able to login till session s not expired.