You are here: Re: [PHP] PHP 5.0.3 and base64 encoded cookie value issue? « PHP « IT news, forums, messages
Re: [PHP] PHP 5.0.3 and base64 encoded cookie value issue?

Posted by Pink Floyd on 10/03/59 11:10

Greetings,
I tested Richard's suggestion below, and it appears
that 'urlencode' is not the function that I want.
Are there any other options? Does anyone know what
PHP uses internally to 'munge' the cookie? I looked at
the php.ini doc's and I could not find any option to
turn off whatever 'encoding' PHP uses internally.

From the spec, it appears that the encoding of cookie
is recommended but not required. Obviously, our non
php server uses base64 encoding for the cookie. So the
question would be can we plug-in a handler to change
the decoding for what-ever php uses or even better to
turn it off?

Thanks
MK


--- Pink Floyd <wavy2gravy@yahoo.com> wrote:
> Richard,
> Thanks for clearing that up. I figured the value
> was
> transformed by the parser, but I did not know that
> it
> could be urlencode. I will test it tomorrow and
> confirm that it is so, I tried to look in the manual
> but did not find it anywhere.
> Thanks a lot.
> MK
> --- Richard Lynch <ceo@l-i-e.com> wrote:
> > Pink Floyd wrote:
> > > (I had posted this in the Zend php-general
> mailing
> > > list
> > > but it did not show up in php.net, so here it is
> > > again)
> > > Greetings,
> > > I am not sure whether this is a bug or a
> 'feature'
> > > (new to PHP). I have a cookie that is set by our
> > > password server (NON-PHP) for our domain, whose
> > value
> > > is base64 encoded when set.
> > > Now, when I try to retrieve the Cookie from my
> > > PHP/Apache Web server the $_COOKIE['token']
> value
> > is
> > > messed up. What I have noticed is the '+'
> > character is
> > > being replaced by ' '.
> > > I have the magic_quotes_gpc set to 'off' and
> > > variables_order set to 'gpcs' in my php.ini.
> > > Currently, I have hacked around by painfully
> > parsing
> > > the $_SERVER['HTTP_COOKIE'] variable and
> > extracting
> > > the 'token' cookie, where its value appears to
> be
> > > intact as set by our password server.
> > >
> > > I would like to avoid this hack if possible, is
> > there
> > > a way to retrieve the 'raw' cookie value without
> > php
> > > 'cleansing' it?
> >
> > There is a raw_headers variable, but it would be
> > even more to parse than
> > what you've got...
> >
> > It occurs to me, though, that PHP is almost for
> sure
> > using the same
> > under-lying code as http://php.net/urldecode and
> you
> > could just take the
> > cookie value you get and pass it through
> > http://php.net/urlencode to
> > "undo" the decode that PHP did.
> >
> > They're inverse functions, so it should be safe to
> > do that for any/all
> > munging that gets done, not just "+" <-> " " but
> > also any %XX that happens
> > to occur in your base64-encoded value.
> >
> > Still a "hack" but far less painful than parsing
> the
> > raw Cookie stuff
> > yourself, and you're less likely to screw up and
> > miss some kind of
> > "gotcha" with % or + or space or...
> >
> > If there *IS* a way to turn off PHP URL decoding,
> > it's gonna be in php.ini
> > and it's gonna be documented right in there.
> >
> > PHP doesn't have a bunch of undocumented
> "features"
> > that you rely on to
> > work. :-)
> >
> > PS It's a feature:
> > [Netscape Cookie spec excerpt]
> > "This string is a sequence of characters excluding
> > semi-colon, comma and
> > white space. If there is a need to place such data
> > in the name or value,
> > some encoding method such as URL style %XX
> encoding
> > is recommended, though
> > no encoding is defined or required."
> >
> > Since data often *DOES* have white space
> semi-colon
> > or comma (yours
> > doesn't, but that's the exception) then you have
> to
> > do SOME kind of
> > encoding on it.
> >
> > It's a lot easier to just always
> urlencode/urldecode
> > it than to document
> > and code every chunk of data that might or might
> not
> > have those
> > characters, and then only encode/decode the ones
> > that need it.
> >
> > base64 encoding is also a fine choice, of course,
> > but it's also easier to
> > handle untrusted data of Cookies, POST, and GET
> all
> > the same, and GET has
> > to be urlencoded, so urlencoding is the choice
> made.
> >
> > So you basically want to do:
> > $token =
> > base64_decode(urlencode($_COOKIES['token']));
> > and Bob's your uncle.
> >
> > --
> > Like Music?
> > http://l-i-e.com/artists.htm
> >
> >
>
>
>
>
> __________________________________
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web
> http://birthday.yahoo.com/netrospective/
>




__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация