NYCPHP Meetup

NYPHP.org

[nycphp-talk] Session basics

Matthew Terenzio matt at jobsforge.com
Mon Aug 22 16:59:26 EDT 2005


As far as I understand, session.use_only_cookies should NOT rewrite the 
URL even on the first page.
session.use_cookies  WILL rewrite the first page and decide from then 
on whether to use cookies (if enabled) or continue rewriting.

someone else can chime in if this doesn't sound right.

Matt

On Aug 22, 2005, at 2:32 PM, Brian O'Connor wrote:

> That seems to be the same problem I'm having, so is it okay that the 
> URL only gets rewritten on the first page?  Because that's all I'm 
> seeing as of now, but I thought that was almost as dangerous as it 
> being there all the time.
>
>  Appreciate the help.
>
> On 8/22/05, Matthew Terenzio <matt at jobsforge.com> wrote:
>>
>> http://lists.nyphp.org/pipermail/talk/2005-January/013648.html
>>
>>
>> On Aug 22, 2005, at 12:29 PM, Brian O'Connor wrote:
>>
>> > Ahh, now I'm still confused :\
>> >
>> >  I added this to a main included file at the top:
>> >
>> >  ini_set("session.use_trans_sid", 0);
>> >
>> >  ini_set("session.use_only_cookies ", 1);
>> >
>> >  However, I'm still seeing "?PHPSESSID=xxxxxxxxxxx" in my URL's.
>> >
>> >  I apologize in advance if I'm getting this wrong, but I tested it 
>> in
>> > IE and Firefox, and no luck either way. Not to mention that cookies
>> > are enabled on both browsers so it shouldn't even be resorting to 
>> the
>> > URL.
>> >
>> >  I then put
>> >
>> >  echo ini_get("session.use_only_cookies");
>> >
>> >  and the output is 1, but it is still giving the sessid through the
>> > URL. If anyone knows whats going on, I would appreciate some help
>> > fixing this :\ Thanks.
>> >
>> > On 8/21/05, Billy Pilgrim <bpilgrim1979 at gmail.com>
>> > wrote:shiflett at php.net> wrote:
>> >> > Aaron Fischer wrote:
>> >> > > If the session has expired such as in browser close or timeout,
>> >> the
>> >> > > bookmarked page won't be a liability as the session id in the 
>> URL
>> >> won't
>> >> > > find a matching session id on the server.
>> >> >
>> >> > The server doesn't know when the browser is closed, so that 
>> part's
>> >> not
>> >> > right. It is true that a session timeout (on the server side) 
>> offers
>> >>  > some protection against this type of accidental hijacking.
>> >>
>> >> A bookmarked session id might not result in a hijacked session, but
>> >> it's not a good idea have session ids exposed and kept around like
>> >> that.
>> >>
>> >> Consider another example:Someone is logged into a newspaper site 
>> and
>> >> sees an interesing article.The user copies the url (with session 
>> id)
>> >> and pastes it in an email to a friend.If the friend receives the
>> >>  email quickly and the server has a long timeout, accidential 
>> session
>> >> hijacking could occur.
>> >>
>> >> The primary reason to have a session id in the url is if the 
>> browser
>> >> doesn't support cookies, right?
>> >> _______________________________________________
>> >> New York PHP Talk Mailing List
>> >> AMP Technology
>> >> Supporting Apache, MySQL and PHP
>> >> http://lists.nyphp.org/mailman/listinfo/talk
>> >>   http://www.nyphp.org
>> >
>> >
>> >
>> > --
>> > Brian O'Connor_______________________________________________
>> > New York PHP Talk Mailing List
>> > AMP Technology
>> > Supporting Apache, MySQL and PHP
>> > http://lists.nyphp.org/mailman/listinfo/talk
>> > http://www.nyphp.org
>>
>>
>> _______________________________________________
>> New York PHP Talk Mailing List
>> AMP Technology
>> Supporting Apache, MySQL and PHP
>> http://lists.nyphp.org/mailman/listinfo/talk
>>  http://www.nyphp.org
>
>
>
> -- 
> Brian O'Connor_______________________________________________
> New York PHP Talk Mailing List
> AMP Technology
> Supporting Apache, MySQL and PHP
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.nyphp.org




More information about the talk mailing list