If I have many settings that I want to store in a cookie, should I create multiple cookies with one option each, or one big cookie with multiple options in a serialized array or something?
Are there any pros/cons for either approach? What do most people do?
Well, mostly we do sessions -- send a single cookie with an identifier for the user, and store all the option values on the server. But if I really didn't want to do a session for some reason, I suppose I'd probably do the single cookie on account of it creating less network traffic if done properly.
A good reason to have separate cookies is so each one is independent of the others, that is to say, an individual cookie can then be expired without affecting other ones, which is not possible if you have everything stored in one big cookie.
Your options are:
PHP Sessions - No cookies required. Store all the data you want. Once the browser is closed or the session is closed new authentication is needed.
Persistent Sessions - One cookie with one value which is either the session key used to access stored sessions or used to access a database table with session information. You can store all the data you want and you have the benefit of not worrying about signing in all the time.
Cookie Only - Storing multiple values in a cookie is not always the best of ideas. Why? 1) Cookies are insecure and can be read by anyone. 2) keeping up with multiple cookies throughout your application can be a source of future bugs. 3) Depending on the client/browser to provide you with accurate data is never good. If you use cookies, make sure they have as light of a footprint as possible.
Big cookies only give you a tummy-ache. Eat Cake instead.
I'd prefer a serialized array....
Cookies are files stored on the client's machine or the server, so less is better.
Related
In relation to How to create a secure login system using cookies and sessions?
I'm building a simple forum, spending my time securing $_SESSION => hashing as mindful person about security but simple one because my future website will be not something giant, I will enable SSL.
Will I need cookie(s) for example about Google Search Console/day's visitors/SEO or nothing special about that and general security ?
Thank you for your help
The Sessions and Cookies both serve the purpose of storing data.The sessions are made at the server and gets destroyed once the connection with the server is lost or the application is closed, while the cookies are made at the client and stays for a defined time, either the application is opened or closed.And you can delete them anytime you wish.
So in relation to the security, the sessions are more appropriate than the cookies.
The latter part of your question is a kind of vague to me, yet I think this answer will be of some help to you. :D
You can find a Cookies vs. sessions comparison here.
There are three main ways, we can get data from our users.
By typing a url or click a link which will be a GET request.
By submit a form which will be a POST request.
Pulling values out of their browser COOKIE that send with every request they make.
and there is one more method to get data which is -
SESSION
sessions are related to cookies.
A session is a file that stored on the web-server file system not on the browser side.
So, when we want save some information, the process is instead of sending a cookie to the user, we send them as a reference to that session file.
So on every request they make to the web server after that they send the reference and were able to lookup that session file and pull all the data out of it.
So the most important difference with sessions that they stored in server-side not client-side.
All we send to the client is a reference to help us find that file.
Using sessions has some benefits and drawbacks -
PROS -
More storage than cookie.
cookie is limited to 4000 characters maximum.
for session, it is limited to only by the file storage size that you have on a web server i.e; how big is the hard-disk, that's the limit.
Smaller request sizes because session uses reference.
Conceals data values.
More secure, less hackable.
CONS -
Slower to access.
You won't see much difference on camparing to cookies, but it is.
Expires when browser is closed.
Cookie can live 6 months or more.
Session files accumulate.
We want to use sessions instead of cookies for keeping track of a few things. However, when I close my browser, and I reopen a page to echo a session var, it doesn't exist (which is how it is suppose to be). Is it possible to prevent this from happening with some magic or anything?
This is not a duplicate question, all I see are people wanting to destroy sessions, I want to do the opposite and retain the session for as long as possible.
Any knowledge would be appreciated.
The right way of doing this is with a database, you can mimic or control php sessions and store them in a database instead of in a file ( as normal ). Then once you have control of the data you can base renewing session via the ip address or better yet by login.
So say a user logs in and then you need to store some data, you store that in the session but php will store it in your database table ( when configured correctly ). Latter the user comes back, initially any visitor would get a fresh session, however once they login you would be able to retrieve the past session they had. You generally don't have much control on if or when a client will delete expired cookies.
This topic is too extensive to put just a few pieces of example code but I did find this small article on the topic.
http://culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/
The guts of it is to use this function, session_set_save_handler
http://php.net/manual/en/function.session-set-save-handler.php
Once you have control of the data you can do whatever you want, however I would caution you about relying only on the IP address and it would be preferable to use a login system for something like this to prevent serving the session up to the wrong visitor.
You cannot reliably control what happens on the client side, even using a separate cookie would not be reliable and would have the disadvantage of storing data on the client where it could be accessed instead of keeping it on your server. Sessions are controlled by cookies but the data in them remains on your server, the cookie just identifies the client.
As a side note, I personally dislike using sessions at all. It may be possible to store what you need in the url, then it can be bookmarked. The classic example would be input for a search form ( via $_GET ) or for paging purposes. There is nothing wrong with doing this if it's not secure data. The problem with sessions is if the data is for a page such as my "classic example" or for paging you get only one session, so you would only be able to have one set of search data at a time, in the url you could have several sets of search data open at once. That said it does largely depend on what you need to save or persist.
Reset the session cookie manually.
$lifetime=60*60; // duration in seconds
session_start();
setcookie(session_name(),session_id(),time()+$lifetime);
You can use session.gc_maxlifetime and session_set_cookie_params, i.e.:
// server should keep session data for AT LEAST 1 Year
ini_set('session.gc_maxlifetime', 3600 * 24 * 365);
// each client should remember their session id for EXACTLY 1 Year
session_set_cookie_params(3600 * 24 * 365);
session_start();
Note:
You can also change the session options globally by editing php.ini -
Session configuration options
PHP sessions use session cookies. Browsers have their own ways of dealing with them but they all consider them to be trash if you close the browser.
Session cookies are not and can not be made persistent. If you need persistent cookies, just use a regular cookie to save a user identification code that your server would recognize, and save their session information in a database or flat file indexed on that id code.
Note that accumulating sessions on the server progressively causes important performance and security concerns.
Note on other answers: All of them mention ways to extend the session cookie expiration which will not overcome the regular behavior when you close your browser window.
Question basically says it all. I get a lot of traffic, about 200k hits a day. I want to store the original referrer (where they came from) in a session variable for various purposes. Is this a good idea or should I stick in a database instead?
You can do both at once :). PHP allows you define the storage logic of your sessions in scripts. This way it is possible to store sessions in a database as well. Check the manual of set_session_save_handler()
Using a database would have its advantages if you use load balancing (or plan to do it once). This way all web servers could read the session data from the same database (or cluster) and the load balancer would not have to worry about which request should be forwarded to which web server. If session data is stored in files, which is the default mechanism, then a load balancer has to forwared each request of a session to the same physical web server, which is much more complex, as the load balancer has to work on HTTP level.
You could just store the information in a cookie if you only need it for the user's current session. Then you don't need to store it at all on your end.
There are a few down sides as well:
They may have cookies disabled, so you may not be able to save it.
If you need the information next time you may not be able to get it, as it could have been deleted.
Not super secure so don't save passwords, bank info, etc.
So if needing this information is required no matter what, maybe its not the way to go. If the information is optional, then this will work.
The default PHP session handler is the file handler. So, the pertinent questions are:
Are you using more than 1 webserver without sticky sessions (load balancing)?
Are you running out of disk space?
Do you ever intend to do those?
If yes (to any), then store it in a database. Or, even better, calculate the stuff on every request (or cache it somewhere like Memcached). You could also store the stuff in a signed cookie (to prevent tampering).
So I have 2 domains: http://domain1.com and http://domain2.com
domain1.com has a bunch of cookies for the user stored on it.
I want to access all of those cookies but from domain2.com (to keep them synchronized).
Is this possible in JQuery? I was thinking of making a Cookie php file and somehow connect to that file from domain2.php to pull all of the data in.
Thanks for any help
NOTE: These are NOT sub-domains but 2 completely different domains I Control
In a strict sense? No. It isn't. In a more loose sense, yes it is.
If you're storing all of your data in cookies, you're actually storing the data in the browser, which means that jQuery, Prototype, Mootools... can't help you because of browser security (unless you can turn their browser into a server (might work with a Firefox extension (I swear, FF could be an OS if needs be...), but that would be gratuitous)).
I said that in a loose sense it is possible because PHP lets you do two very important things. First, it lets you store your session in a database, and second it lets you assign the session ID directly. It is possible, then, to have two servers point to the same DB and then share SESSION data by switching the user's session ID.
no. this would violate the security model on which browser cookies operate.
to work around this you can implement an iframe (perhaps invisible to the user) on domain1.com which is served from domain2.com and pass data between the two sites with JS.
I would look at a server-side solution, creating a common database that all sites can access. When the user logs in, generate a time-sensitive, IP-keyed token that can be passed from site to site either in GET or POST. Then, validate each request on token, IP, and time. The combination of the three will resolve most security concerns.
or you can look at this SO question for ideas its in .Net though Store cookie for other site
I'm making a php web application which stores user specific information that is not shared with other users.
Would it be a good idea to store some of this information in the $_SESSION variable for caching? For example: cache a list of categories the user has created for their account.
This would be an appropriate use of the session mechanism as long as you keep this in mind:
Session does not persist for an indefinite amount of time.
When pulling from session, ensure you actually got a result (ASP.NET will return NULL if the Session has expired/cleared)
Server restarts may wipe the session cache.
Do this for convenience, not performance. For high-performance caching, choose an appropriate mechanism (i.e. memcached)
A good usage pattern would be like this (ether cookies or session):
User logs in
Store preferences (background color, last 10 records looked at, categories) in session/cookie.
On rendering of a page, refer to the Session/Cookie values (ensuring they are valid values and not null).
Things not to do in a cookie
Don't store anything sensitive (use session).
A cookie value should not grant/deny you access to anything (use session).
Trap errors, assume flags and strings may not be what you expect, may be missing, may be changed in transit.
I'm sure there is other things to consider too, but this is just off the top of my head here.
That could work well for relatively small amounts of data but you'll have to take some things into consideration:
$_SESSION is stored somewhere between requests, file on disk or database or something else depending on what you choose to use (default to file)
$_SESSION is local to a single user on a single machine.
sessions have a TTL (time to live), they dissapear after a set amount of time (which you control)
Under certain circumstances, sessions can block (rarely an issue, but i've run into it streaming flash)
If the data you mean to cache is to be accessed by multiple users you're quickly better off caching it seperately.
If you only want this data available during their session, then yes. If you want it available tomorrow, or 4 hours from now, you need to save it to a database.
Technically you can modify the sessions to have a very long lifespan, but realize if they use a different computer, a different browser or flush their cookies they will loose the link to their session, therefore anything serious you should create a type of user account in your application, link the session to their account and save the data in a permeate place.