I started using PHP a couple of months ago. For the sake of creating a login system for my website, I read about cookies and sessions and their differences (cookies are stored in the user's browser and sessions on the server). At that time, I preferred cookies (and who does not like cookies?!) and just said: "who cares? I don't have any good deal with storing it in my server", so, I went ahead and used cookies for my bachelor graduation project. However, after doin' the big part of my app, I heard that for the particular case of storing user's ID, sessions are more appropriate. So I started thinking about what would I say if the jury asks me why have you used cookies instead of sessions? I have just that reason (that I do not need to store internally information about the user). Is that enough as a reason? or it's more than that?
Could you please tell me about advantages/disadvantages of using cookies for keeping User's ID?
Thanks for you all in StackOverflow!
when you save the #ID as the cookie to recognize logged in users, you actually are showing data to users that is not related to them. In addition, if a third party tries to set random IDs as cookie data in their browser, they will be able to convince the server that they are a user while they actually are not. That's a lack of security.
You have used cookies, and as you said you have already completed most of the project. besides cookie has the privilege of remaining for a long time, while sessions end more quickly. So sessions are not suitable in this case. In reality many famous and popular websites and services use cookie and you can stay logged-in for a long time. But how can you use their method to create a safer log-in process?
here's the idea: you can help the way you use cookies: If you use random keys instead of IDs to recognize logged-in users, first, you don't leak your primary data to random users, and second, If you consider the Random key large enough, It will be harder for anyone to guess a key or create a random one. for example you can save a 40 length key like this in User's browser: "KUYTYRFU7987gJHFJ543JHBJHCF5645UYTUYJH54657jguthfn" and it will be less likely for anyone to create the exact key and pretend to be someone else.
A session is a group of information on the server that is associated with the cookie information. If you're using PHP you can check the session. save _ path location and actually "see sessions". A cookie is a snippet of data sent to and returned from clients. Cookies are often used to facilitate sessions since it tells the server which client handled which session. There are other ways to do this (query string magic etc) but cookies are likely most common for this.
Basic ideas to distinguish between those two.
Session:
Cookies:
Session is preferred when you need to store short-term information/values, such as variables for calculating, measuring, querying etc.
Cookies is preferred when you need to store long-term information/values, such as user's account (so that even when they shutdown the computer for 2 days, their account will still be logged in). I can't think of many examples for cookies since it isn't adopted in most of the situations.
As others said, Sessions are clever and has more advantage of hiding the information from the client.
But Cookie still has at least one advantage, you can access your Cookies from Javascript(For example ngCookies). With PHP session you can't access it anywhere outside PHP script.
I personally use both cookies and session.
Cookies only used when user click on "remember me" checkbox. and also cookies are encrypted and data only decrypt on the server. If anyone tries to edit cookies our decrypter able to detect it and refuse the request.
I have seen so many sites where login info are stored in cookies, anyone can just simply change the user's id and username in cookies to access anyone account.
Thanks,
SESSIONS ENDS WHEN USER CLOSES THEIR BROWSER,
COOKIES END DEPENDING ON THE LIFETIME YOU SET FOR IT. SO THEY CAN LAST FOR YEARS
This is the major difference in your choice,
If you want the id to be remembered for long time, then you need to use cookies; otherwise if you just want the website to recognize the user for this visit only then sessions is the way to go.
Sessions are stored in a file your php server will generate. To remember which file is for which user, php will also set a cookie on the user's browser that holds this session file id so in their next visit php will read this file and reload the session.
Now php by default clears sessions every interval, and also naming convention of session make it auto expire. Also, browsers will not keep the cookie that holds the session id once the browser is closed or the history is cleared.
It's important to note that nowadays browsers also support another kind of storage engines such as LocalStorage, SessionStorage, and other webdb engines that javascript code can use to save data to your computer to remember you. If you open the javascript console inside Facebook, for example, and type "localStorage" you will see all the variables Facebook uses to remember you without cookies.
Actually, session and cookies are not always separate things. Often, but not always, session uses cookies.
There are some good answers to your question in these other questions here. Since your question is specifically about saving the user's IDU (or ID), I don't think it is quite a duplicate of those other questions, but their answers should help you.
Rules ordered by priority:
Source : https://www.lucidar.me/en/web-dev/sessions-or-cookies/
Sessions use a cookie! Session data is stored on the server side, but a UID is stored on client side in a cookie. It allows the server to match a given user with the right session data. UID is protected and hard to hack, but not invulnarable. For sensitive actions (changing email or resetting password), do not rely on sessions neither cookies : ask for the user password to confirm the action.
Sensitive data should never be stored in cookies (emails, encrypted passwords, personal data ...). Keep in mind the data are stored on a foreign computer, and if the computer is not private (classroom or public computers) someone else can potentially read the cookies content.
Remember-me data must be stored in cookies, otherwise data will be lost when the user closes the browser. However, don't save password or user personal data in the 'remember-me' cookie. Store user data in database and link this data with an encrypted pair of ID / key stored in a cookie.
After considering the previous recommandations, the following question is finally what helps you choosing between cookies and sessions:
Must persistent data remain when the user closes the browser ?
Cookies and Sessions are used to store information. Cookies are only stored on the client-side machine, while sessions get stored on the client as well as a server.
Session
A session creates a file in a temporary directory on the server where registered session variables and their values are stored. This data will be available to all pages on the site during that visit.
A session ends when the user closes the browser or after leaving the site, the server will terminate the session after a predetermined period of time, commonly 30 minutes duration.
Cookies
Cookies are text files stored on the client computer and they are kept of use tracking purposes. The server script sends a set of cookies to the browser. For example name, age, or identification number, etc. The browser stores this information on a local machine for future use.
When the next time the browser sends any request to the web server then it sends those cookies information to the server and the server uses that information to identify the user.
Sessions allow you to store away individual pieces of information just like with cookies, but the data gets stored on the server instead of the client.
Session and Cookie are not a same.
A session is used to store the information from the web pages. Normally web pages don’t have any memories to store these information. But using we can save the necessary information.
But Cookie is used to identifying the users. Using cookie we can store the data’s. It is a small part of data which will store in user web browser. So whenever user browse next time browser send back the cookie data information to server for getting the previous activities.
Credits : Session and Cookie
I will select Session, first of all session is more secure then cookies, cookies is client site data and session is server site data. Cookies is used to identify a user, because it is small pieces of code that is embedded my server with user computer browser. On the other hand Session help you to secure you identity because web server don’t know who you are because HTTP address changes the state 192.168.0.1 to 765487cf34ert8ded…..or something else numbers with the help of GET and POST methods. Session stores data of user in unique ID session that even user ID can’t match with each other. Session stores single user information in all pages of one application. Cookies expire is set with the help of setcookies() whereas session expire is not set it is expire when user turn off browsers.
Criteria / factors | Sessions | Cookies |
---|---|---|
Epoch (start of existence) | Created BEFORE an HTTP response | Created AFTER an HTTP response |
Availability during the first HTTP request | YES | NO |
Availability during the succeeding HTTP requests | YES | YES |
Ultimate control for the data and expiration | Server administrator | End-user |
Default expiration | Expires earlier than cookies | Lasts longer than sessions |
Server costs | Memory | Memory |
Network costs | None | Unnecessary extra bytes |
Browser costs | None | Memory |
Security | Difficult to hijack | Easy to hijack |
Deprecation | None | Now discouraged in favor of the JavaScript "Web Storage" |
Advantages and disadvantages are subjective. They can result in a dichotomy (an advantage for some, but considered disadvantage for others). Instead, I laid out above the factors that can help you decide which one to pick.
Let's just say you are a server-side person who wants to process both the session and cookie. The first HTTP handshake will go like so:
In step 1, the browser have no idea of the contents of both sessions and cookies. In step 4, the server can have the opportunity to set the values of the session and cookies.
Let's say in a single web page you are loading 20 resources hosted by example.com
, those 20 resources will carry extra bytes of information about the cookies. Even if it's just a resource request for CSS or a JPG image, it would still carry cookies in their headers on the way to the server. Should an HTTP request to a JPG resource carry a bunch of unnecessary cookies?
There is no replacement for sessions. For cookies, there are many other options in storing data in the browser rather than the old school cookies.
Session is safer for storing user data because it can not be modified by the end-user and can only be set on the server-side. Cookies on the other hand can be hijacked because they are just stored on the browser.
Source: Stackoverflow.com