A question with Cookies

Namadoor

Is there a way to use cookies without having session_start() ?

mykg4orce

i think ur getting Session and Cookies confused, they are separate things. They can be used independently.

To use session_start(); and then using session_register("myvar"); is telling the PHP server to store all session variables in a "tmp" directory. So a script that uses sessions does'nt leave those variables on your computer it stores it on the server and tracks it by the session_id();

But a script that uses a Cookie leaves a file your computer, you dont have to use session_start(); to set a cookie:

<?php
$value = "testing this thing";
setcookie ("TestCookie", $value);
?>

for more info on setting cookies look here:
http://www.php.net/manual/en/function.setcookie.php

MrAlaska

Although it is possible to store a session ID in the URL, most sites use cookies to store the session ID. If you set a cookie without an expiration date, it does not get written on the client machine. In that case, you are doing much the same thing as sessions do except storing a little more data in the client's RAM instead of the server, which can make a significant performance impact if you have a lot of visitors.

I am keeping myself open on the subject, but I have not yet heard any compelling arguments regarding the convenience of sessions outweigh the performance loss.

yelvington

Mr. Alaska, what you posted doesn't make sense.

There are only two ways to get around the inherently stateless nature of the HTTP protocol:

A. Send the persistent data back and forth over the wire with every transaction. Cookies, url-encoded variables, hidden form variables, and HTTP BASIC authentication are examples of this.
B. Store the persistent data temporarily on the server side, and send a small, unique key back and forth over the wire with every transaction, using one of the methods defined in A. Retrieve the saved data using the key.

Sessions implement method B. They reduce the amount of network traffic, significantly enhancing performance if large amounts of data are involved. Because the key is automatically generated and non-predictable, they also provide a higher level of security.

Cookies often are adequate and, because they are more convenient, appropriate for situations where there is not a high need for security, the data is limited, and the data may need to persist for long periods of time (i.e., permanent unique user IDs, default login to nytimes.com, et cetera).

MrAlaska

What doesn't make sense?

Just by having sessions turned on, the server allocates a certain amount of RAM to each user whether they need it or not. Obviously, with enough users performance will be shot if the server is spending a signifigant portion of its cycles keeping track of all the variables. Storing the variables on the client side takes a tremendous load off the server.

The unique key sessions store on the client can just as easily be generated in your code and stored with the cookie. I agree important data does not belong on the client side, but to use sessions to store nothing more than an encrypted password and user name I don't see sessions as introducing any more security than cookies storing the same along with a unique key generated by your server side script.

yelvington

If you are saying that the server allocates RAM to store PHP session data between requests, you are mistaken. Session variables are stored in files, not in memory space belonging to the HTTP process. (The operating system may buffer the files in RAM, but that's an external issue.)

In fact, you can kill and restart a Web server without deleting active sessions.

Files are used because there is no guarantee that the same server process will serve the next request, particularly with Apache 1.x, which is a preforking server and not a threaded server.

On a Web cluster, is even possible for multiple server boxes to be involved, and so long as they share a session storage system (such as an NFS-mounted directory, or a database, if you write the necessary code).

Session data is inherently more secure than cookie, post, and get methods because it does not retransmit the variables in plaintext over the Internet. The session ID is visibly transmitted, but the data itself remains hidden server-side, available only to the server.

It's possible to hijack a session ID and therefore a session, so if you need bulletproof security, you should still be running on an encrypted connection (https server).

The other thing you said is that client-side storage does not place a load on the server. This is not true, because the client retransmits the entire cookied data set along with every request. This slows down the transaction, requires that the Web server keep the connection open for a longer period, and has a much more deleterious effect on overall performance than server-side storage.

If you run a packet sniffer on an ethernet segment attached to a Web server, and monitor Port 80 traffic, you can see all of this happening, by the way.

MrAlaska

I cannot speak specifically for PHP because I have not seen it documented, but typical behavior for a server is to allocate a specific amount of RAM to each user to keep track of the session itself, not the variables. (EDIT:clarification. When I mentioned variables above I was referring to server-session variables as opposed to PHP-client variables) In the case of the server restarting this stash is rebuilt from stored information. With sessions turned on, a user who has not even logged in is putting the same load on the server as a user with a full shopping cart.

I did not say client side storage does not place any load on the server, I said it removes load. Naturally, storing a lot of variables on the client can kill the network. I don't advocate cookies for storing any more than basic (ecncrypted) identification.

Sessions are a secure and convenient place to store variables, but at this point it still seems to me the variables can be handled more efficiently by explicitly dealing with them on the server side through your script.

PHP might have evoked more efficient ways of running sessions, if so I am all ears. I have been looking for such documentation ever since I read the first article exclaiming, 'Sessions are the answer!'.