Disable session IDs in URL

[computergenius]

I have seen the method to disable session IDs which appear in URLs in various places on the internet.

What I don't see, is what difference it makes. OK, the URL changes - but surely there is a downside somewhere?

How are the sessions passed from page to page without the PHPSESSID in the URL?

[mikesmith76]

the session id can be passed either in the url or via a cookie. There is no difference between the two methods with regards to the session functionality.

there are other issues to consider, such as session hijacking, which may influence which method you use

[kgun]

Don't pass them via the URL.

CXLII. Session Handling Functions

Read the part: Sessions and Security.

PDF document: Session Fixation Vulnerability in Web-based Applications.

session_id

Function: session_get_cookie_params

Related WPW thread: php sessions for storing data

[computergenius]

I should have said that the information is not required to be secure.

If I switch the URL Session ID off, then am I correct in saying that the session ID will be passed via cookies, and that the information that the session carries will be kept on the server?

Should I be worried about people switching off cookies?

An example would be the language that the person was viewing in, or the data being viewed.

My concern is that if I don't pass the session in the URL, then if the visitor has cookies off, then the pages presented will be confusing, and may not work.

[kgun]

To clarify (assuming PHP):

1. Sessions are a mechanism that allow PHP to preserve state between excecution.
2. First PHP generates a unique thirty-two character string to identify the session.
3. It then passes the value to the browser and simultaneously it creates a file on the server and include the session ID in the file name. So the only thing that's stored in the browser is a single cookie that contains the users session ID. One of the big selling points of PHP sessions is that they also work when cookies are disabled. If PHP detcts that cookies are disabled in the user's browser it will automatically add the session ID as a query string variable on all relative links on your page, thus passing the session ID onto the next page. For this to work, session.use_trans_sid must be enabled in your php.ini file.
4. There are two methods by which PHP can inform a browser of its session ID:[list:464f72f000]
5. By adding the ID to the query string of all relative links on the page or
6. by sending it as a cookie

[*] Within the file that's stored on the server, PHP saves the names and values it has been told to store for the session.[*] Sessions may not only be stored on the server as files. It's also possible to store them in a database or even in shared memory. This can be useful for load balancing multiple Web servers using a single session repository, allowing visitors to (unknowingly) swap servers while maintaining their session.[*] This only works on .php pages of your site. [/list:o:464f72f000]

Note: If you ever need it, you can add the session ID yourself to absolute URL's like this:

<?php
session_start();
?>

MySite

[computergenius]

Originally Posted by kgun

If PHP detcts that cookies are disabled in the user's browser it will automatically add the session ID as a query string variable on all relative links on your page, thus passing the session ID onto the next page. For this to work, session.use_trans_sid must be enabled in your php.ini file.

That is the bit I was looking for... Tussen tak!

But (...there is always a but!<G>) what about Googlebot et al? I would expect (for no reason) that these robots work "with cookies disabled". Which will bring the session IDs back into the URL, and back into the search engine listings. Or am I wrong in my supposition?

[kgun]

Your question is deep. I may give you some hints:

1. Search Engine-Friendly URL's May be temporarily (or permanently?) down.
2. The Apache web server behaviour versus PHP. While Apache is blind to the URL suffix, PHP is not.
3. That means that you have two methods to manage this. KW's[list:d59e0c583c]
4. Hiding PHP scripts with force type.
5. Hiding PHP scripts by rewriting URL's.

[*] There is a Class PathVars in the SPLIB library that follows with the book Harry Fuecks "The PHP Anthology: Object Oriented PHP Solutions" that handles this in a more efficient way. That book is hereby reccomended. [/list:o:d59e0c583c]

P.S.
Thank you very much = "Tusen takk"

in Norwegian :-)

[Easywebdev]

When php started to take off things were added to the language as "helper" functions trying to preempt the thought process of the programmer and many of these so called "helper" functions/settings are now deprecated in v6 . register_globals was defaulted to off with php4 and will not exist in 6 nor will magic_quotes_gpc() and set_magic_quotes_runtime(). These are nothing more than a hindrance as you have to check whether they are on or off and take appropriate action when you really should be using the databases native quoting functions.

The php ssessions functions are something I honestly believe that no one should be using. For me they were an ill thought out addition to the language and I and many others are advocating they be deprecated with php 6. You have hit the nail on the head above with what happens if cookies are disabled and session_trans_sid is on. Again the programmer must go writing code to see what is and isnt enabled and take appropriate action. Not a "help" in any sense of the word.

Writing a database session class can be as simple or as complex as you need it to be and it is up to you how you pass the session identifier not on a configuration file that may or may nor have the features you require enabled.

The main advantage of using database sessions is that session fixation is impossible (the session will not exist in your database) and your only concern is packet sniffing/cookie theft.

[kgun]

Yes, there are too many configuration variables. The languages are getting better as it matures. C++ started as C with headers.

You get a fairly good overview of the developement cycle of PHP from this PHP Developers Meeting.
Note the following:

• 5.5 Object casting to primitive types.
• 5.6 name spaces.
• 5.12 Delegates.

A PHP 6 overview: By Danne Lundqvist
"The register_globals, magic_quotes and safe_mode will finally disappear and hopefully slowly fade away into distant memory. It seems PHP 6 will even refuse to start if these settings are found in php.ini. Dropping support for the long versions of super globals, like HTTP_POST_VARS, is also scheduled. This is long overdue."

He is developing a hosted application, a help desk system, in PHP using the Zend framework.

[Easywebdev]

The PHP developers are still patching and adding functionality with each release but their hands are tied with "backward compatability". I'm sure there are a lot of features they would like to remove/alter but cannot due to breaking older scripts.

There has not been a huge uptake of php5 in the hosting industry (developers are not using it for commercial applications for this reason alone, hosters arent adopting it as there are few scripts written in it, catch22) and I dont see much of an uptake of 6 either unless it is a new standalone version. I would like to see the developers bite the bullet on v6 and forget backward compatability and implement everything they would like to in 6 and release it as a seperate language. Some hosts have phpv4 and phpv5 installed on their systems and it would be easy to provide a v6 version too.

The only thing I would really like added to v6 is variable casting as standard.

[kgun]

Originally Posted by Easywebdev

I would like to see the developers bite the bullet on v6 and forget backward compatability and implement everything they would like to in 6 and release it as a seperate language.

Fully agree. My Danish hoster has 5.14 installed. PHP 5.2.0 was released Nov 02. A good hoster should

• Offer an option to use the last and an older stable version.
• The last version should be available at least for experimental purposes no later than a month after it was launched.

To go back to topic, the future may be uncertain for session variables. The best solution is therefore to write a session class that we wrote about in the other WPW session thread menitioned above.

That is the good thing about classes. You only update the class API and you do not need to rewrite your older classes. A good OO design make your code more forward compatible.

I like this cite from the preface to volume II by Harry Fuecks.

"If I had one goal in mind with writing the PHP Anthololgy Object Oriented PHP solutions, it was to demonstrate just how easy it is to create intricate and powerful Web applications with the object oriented approach. In many cases, the more common procedural approach would result in unmanageable and bug-ridden "spaghetti code.""

More and more pople understand that. The drinks machine (automaton) that has its inner workings ("API") changed functions just as before. The user does not see the change and he need not worry about it. He hists the same buttons. If the designer wants to add new drinks to the automaton, he extends the API (class inheritance). The user only sees some new buttons (methods.) The inner working of the drinks machine is encapsulated. OOP in a nutshell.

Final recommendation: Write / import a session class, and you will not loose your hair so fast.