I also use those sessions when checking on the apache logs. For a specific user, so i can trace what he did. On 4/12/06, Richard Lynch <ceo@xxxxxxxxx> wrote: > > On Tue, April 11, 2006 12:40 pm, Alain Roger wrote: > > I would like to understand the purpose of placing SESSION_ID within > > the URL. > > I suppose it is for security improving... However, how to do it ? > > > > i mean how can it be useful ? how can i use it ? > > Actually, unless you are using SSL (https://example.com) then it > REDUCES security as somebody *could* intercept the session ID. > > What it increases is browser-compatibility -- Specifically, it allows > browsers and other user agents that do not accept/return cookies to > use a session. > > Some users, such as myself, do not generally allow Cookies unless they > want the content bad enough, and trust the site to not be sharing > personal/trackable information with other sites. > > It's a pain in the ass, but it's important to me to not get as much > JUNK mail, email, etc and I *KNOW* sites are doing this kind of thing > when I use unique email addresses and they cross from one site to the > next. > > E.G., just yesterday the City of Chicago sent spam to a unique email > address I gave to PIRG. > > If your cookies are always on, always accepted, you have to assume > that SOME sites are tracking you, sharing the URLs you visit with > other sites, and sharing whatever personal info they can find out > about you with their partner/affiliate sites, who can then target > their advertising (on-line and off-line) at you. They've invariably > wrapped this all up in a very long-winded "Privacy (sic) Policy" which > nobody reads anyway. > > Using Sessions in the URL can be as simple as turning on the options > in php.ini, or using .htaccess to turn them on. > > You could also roll your own to embed the session ID in the URLs you > care about, ignoring, for example, images and javascript and CSS, and > thus making your site SLIGHTLY less standard and amenable to attack > from a shotgun random-selection of victim. Of course, that's > off-balanced by your maintainability of the code you have to > write/maintain yourself to handle the session ID. It's not a TON of > code, for some well-structured applications, so in some cases it's > probably "worth it" > > There are also some techniques you can take to validate the user with > session IDs over non-SSL connections: > Alter the session ID on a regular basis, so that "old" IDs are void > Embed a second token in the GET/POST data that also expires > Challenge users for passwords before particularly sensitive actions > > -- > Like Music? > http://l-i-e.com/artists.htm > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Louie Miranda (lmiranda@xxxxxxxxx) http://www.axishift.com //JSM-W
