Cookies vs Sessions

[s0c0]

I am writing your standard login and insert, read etc... from a mysql database web app.  When storing a users login name for queries and the like should I be using cookies or sessions?  This is what I read:

 

Cookies can be set to a long lifespan, which means that data stored in a cookie can be stored for months if not years. Cookies, having their data stored on the client, work smoothly when you have a cluster of web servers, whereas sessions are stored on the server, meaning in one of your web servers handles the first request, the other web servers in your cluster will not have the stored information.

 

Sessions are stored on the server, which means clients do not have access to the information you store about them - this is particularly important if you store shopping baskets or other information you do not want you visitors to be able to edit by hand by hacking their cookies. Session data, being stored on your server, does not need to be transmitted with each page; clients just need to send an ID and the data is loaded from the local file. Finally, sessions can be any size you want because they are held on your server, whereas many web browsers have a limit on how big cookies can be to stop rogue web sites chewing up gigabytes of data with meaningless cookie information.

 

Since the information my app will be storing is nothing financial or anything serious and if things went well it would be nice to have a cluster of servers should I then be using cookies?  For now I will continue writing using sessions, but please do let me know if I should make the switch as it will only take a few minutes of find and replace.

[bibby]

The only downside, imo , to sessions if that you have to include session_start() at the top of each script.

That said, sessions are the way to go, especially for logins.

 

People can mess with their cookies...  make them never expire for instance.

 

With sessions, they have no control anymore. Plus, you can stash all sorts of info (ip address, browser info, useful site vars) in the session var and the user won't know or care because it's your on your server.

[s0c0]

How many people really mess with their cookies though?  I can't even think of time where I felt the urge to set my cookie to never expire.

[448191]

If you're not concerned with security you CAN use cookies. I don't really see why you would want to though. Better to keep everything nice and centralized and use only a cookie for the session id.

 

Which raises the question: why do you want to use cookies?

[Nameless12]

sessions are cookies

 

A session is a cookie where the cookie value is a primary key to a data source

[448191]

sessions are cookies

 

Oh, come on.  :'(

 

A session is NOT a cookie, don't be telling people that. A cookie CAN be used to store the session identifier on the client. That doesn't make a session a cookie, vice versa or whatever.

 

Cookies == a 'phisical' type of file.

Sessions == periods of time in which a state is maintained.

 

Cookies on the client with information other than a session identifier can also maintain a certain state, thus the period those cookies exist and influence the state of an application may also be called a session.

 

However, that is not recommended because the application has no control over the values of the session data. This can be a sercurity concern, plus it requires full description of the state upon client request.

 

[Nameless12]

like i said, it is a cookie where the value of the cookie is a primary key to some data source. Any vulnerability that cookies have sessions have. You cannot do sessions without cookies unless you constantly put the session_id in the REQUEST_URI and that is not pretty.

 

By default the php session handler is insecure and requires additional security to prevent things like session hijacking. But like I said a sessions are cookies.

 

if ($_COOKIE['session_id'] == 'somekey')

{

$_SESSION['var1'] = 'val1';

$_SESSION['var2'] = 'val2';

$_SESSION['var3'] = 'val3';

}

 

the above is probably the worlds simplest version of sessions, thats really all it is but all the real world implementations just happen to store the data inside a file or memory as opposed to inside the actually file.

 

You could say that you are going to use a cookie as a user_id That would mean the user_id is a primary in a data source. Technically this is a session.

 

sessions in the context of this conversation ARE cookies

[448191]

sessions in the context of this conversation ARE cookies

 

Don't you mean 'when so heavily oversimplicated that is becomes a false statement'?

 

You could say that you are going to use a cookie as a user_id That would mean the user_id is a primary in a data source. Technically this is a session.

 

This is not a session because a session is a period of time. Not code, not files, not an object, not php's session_* session management system; TIME.

 

But for the sake of argument, let's assume you are right. What if I decide to use an urlencoded session id? How are sessions cookies then?

 

I think you'd better re-read my previous post before you start posting oversimplicated defintions of concepts again.

[Nameless12]

When I say sessions are cookies that is because it is just a technique that replies on cookies. There is one other way to do sessions but in the context of this convo no one is talking about sessions via $_GET.

 

A user_id is a primary key to a list of users, a list of users is persistent data. If the cookie is a primary_key in any shape or form is it technically a session.

 

Some will disagree because they are used to using session_start() but when you write a session handler on your own it is exactly how I am saying.

 

The reason you constantly hear about session_start needing to be at the top of the page is becuase headers have to be at the top of the page and cookies are sent in the headers

 

What I said is not overly simplified. when you run session_start() it sets a cookie and then creates a file with the cookie value as its name if the file\cookie does not exist already

 

At the end of the page $_SESSION is serialized and placed inside the file.

 

When the page is reloaded it does not need to create a new file so it unserializes the data and places it in the $_SESSION array.

 

I am tired so i hope i wrote it all down properly. The point is the above process is using a cookie as a primary key whenever that happens it is a session...

 

EDIT::

yes like i said in my last post there is the exception of using $_GET as a way of passing the session_id but seriously, who does that?? I already explained this was an exception prior to your last post.

[448191]

You either fail to compehend or don't want to comprehend because you don't want to admit you made a false statement.

 

You don't have to explain to me how php's session management system works, I know it well.

 

If the cookie is a primary_key in any shape or form is it technically a session.

 

Which part of 'sessions are periods of time' do you not get?

 

You are not the only one confused about this (unfortunately it is a very common misunderstanding), so let me try and explain:

 

• session: period of time in which a certain state between parties is maintained.
  These parties can be a web application and a client, a web protocol server (like a FTP server) and client, or EVEN a shrink and it's patient.
  
• session identifier: a unique identifing property, usualy represented by a string which is associated with the rest of the data within a session.
  
• session management system: a software system to manage the handling of sessions.
  
• cookie: one of a multitude of possible means to store session data in web applications, be it a session identifier or other data.
  
• session_*: set of functions, part of php's build in session management system.
  
• $_SESSION: global variable, part of php's build in session management system.
  

 

You see: a session is NOT a cookie. A cookie is a cookie. A session is session, and a session management system can be IMPLEMENTED in many ways, one of which CAN include the use of cookies as a means of storing a session identifier. Even with php's build in session management system the use of cookies is OPTIONAL: check the manual.

 

If you still don't get it now, I give up. 

[Nameless12]

I cant even be bothered responding to this. Please learn how to make a session handler\management before you continuing this topic. Bye.

 

EDIT::

I said sessions can be implemented multiple ways, all sessions are is really a database and a primary key.... what you fail to realize is this topic is cookies V session, so when i said sessions are cookies it was in the context of the topic

[redbullmarky]

and i always thought cookies were a type of biscuit...

 

chaps, keep the noise down a little bit...

[448191]

Sessions !=== Cookies

 

In no context.

 

If you would've said "sessions usually use cookies", which is a milder simplification, I would have supported that statement.

 

Sorry Mark, guess I am letting this getting under my skin a little bit.

[ted_chou12]

and i always thought cookies were a type of biscuit...

you made me a bit hungry...

Ted

[Nameless12]

You are playing on technicalities in wording. My point was sessions are a primary key.

 

Most 3rd party session handlers are designed for cookies and not $_GET and $_POST. Why I think $_POST would be a smart way to do it there is a reason why its not used. $_POST is not offered by phps session handler and $_GET is considered bad practice.

 

Just because sessions happen to allow $_GET does not mean it should be used. Also sessions are not limited to php and I think you will find most of them are designed for cookies. The only exception is when people choose to allow another option.

 

Sessions are nothing but a primary key, to say cookies that are used as primary keys are sessions is accurate. Why you may be anal about my wording or the fact you read it in a different context that is your problem.

 

Learn how to make a session handler before you go around acting as if you know everything about them.

 

I will not be replying to this topic anymore. If any of the admins feel like giving me a warning for being a little rude please ban me instead.

 

goodbye

[s0c0]

....so I decided to use sessions instead!

[utexas_pjm]

....so I decided to use sessions instead!

 

hahaha.

[worldworld]

For more details click here...

[tauchai83]

What a good URL given by -worldworld!    Cool down everyone.

[roopurt18]

Use sessions for data you wish to store while the user is browsing your site.

 

Use cookies for data you wish to preserve between user visits.

 

Limit the amount of information you store in each to the bare minimum; it should only be enough to identify the user and pull data about them from the DB.

 

My $.02 on the internal argument:  sessions are not cookies, although they perform much of the same task.  If a session was a cookie, there wouldn't be a sessions vs. cookie discussion IMO.