$_GET is Mangling Base64 value

----f23fa7029b4bb6e7f1198
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all Is there an issue with $_GET not handling a Base64-encode=
d value correctly=3F (PHP is 516)
Am receiving a Base64-encoded value=3A

theurlcom/indexphp=3Fmessage=3Dxxxxx

=A0and retrieving it with $_GET=3A

echo $_GET["message"]=3B

xxxxx is a Japanese phrase=2C that has been encoded into Base64 So is=
using the + symbol=3A

..OODq+OCou..

but my $_GET is replacing the + with a space=3A

..OODq OCou..

thus the=A0base64=5Fdecode() is failing (displays diamonds with question=
s marks on my Mac)

The Base64-encoded string=A0is 156 characters long=2C if that has any b=
earing My test URL is 230 characters in total=2C less than the =22old=
=22 256 limit
All I can find online is a reference that PHP will no longer assume tha=
t a space is a +=3A

=3Chttp=3A//ca3phpnet/manual/en/functionbase64-deco dephp=236=
9298=3E

but my problem is the opposite - the + symbols are there=2C but the GET =
is removing them
(And to add a wrinkle=2C this then goes into a Joomla! page=2C whose ge=
tVar() command completely removes the +=2C so I couldn=27t even do a str=
ing replace=2C as I don=27t know where the + should have been!)

Tired of looking at the dark red spot on the wall! Thanks


George Langley    Multimedia Developer    Audio/Video Editor =A0=
=A0 Musician=2C Arranger=2C Composer wwwgeorgelangleyca



----f23fa7029b4bb6e7f1198--

Re: $_GET is Mangling Base64 value

--=-mrntz9ai5MSvp5GQuVOg
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-03-11 at 14:57 -0700, George Langley wrote:

> Hi all. Is there an issue with $_GET not handling a Base64-encoded value correctly? (PHP is 5.1.6)
> Am receiving a Base64-encoded value:
>
> theurl.com/index.php?message=xxxxx
>
> and retrieving it with $_GET:
>
> echo $_GET["message"];
>
> xxxxx is a Japanese phrase, that has been encoded into Base64. So is using the + symbol:
>
> ...OODq+OCou...
>
> but my $_GET is replacing the + with a space:
>
> ...OODq OCou...
>
> thus the base64_decode() is failing (displays diamonds with questions marks on my Mac).
>
> The Base64-encoded string is 156 characters long, if that has any bearing. My test URL is 230 characters in total, less than the "old" 256 limit.
> All I can find online is a reference that PHP will no longer assume that a space is a +:
>
>
>
> but my problem is the opposite - the + symbols are there, but the GET is removing them.
> (And to add a wrinkle, this then goes into a Joomla! page, whose getVar() command completely removes the +, so I couldn't even do a string replace, as I don't know where the + should have been!)
>
> Tired of looking at the dark red spot on the wall! Thanks.
>
>
> George Langley Multimedia Developer Audio/Video Editor Musician, Arranger, Composer www.georgelangley.ca
>
>


Do a url_encode() on the string after you base64() it, and it should be
safe for use as a URL

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-mrntz9ai5MSvp5GQuVOg--

Re: $_GET is Mangling Base64 value

On Thu, Mar 11, 2010 at 1:57 PM, George Langley wr=
ote:

> xxxxx is a Japanese phrase, that has been encoded into Base64. So is usin=
g the + symbol:
>
> ...OODq+OCou...
>
> but my $_GET is replacing the + with a space:
>
> ...OODq OCou...
>
> thus the base64_decode() is failing (displays diamonds with question=
s marks on my Mac).

You could always pre-parse it with

$_GET['foo'] =3D str_replace(' ', '+', $_GET['foo']);

and inject them back in... I have had to do something like that in the
past because of the same issue (I either needed to add or remove the +
I forget)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: $_GET is Mangling Base64 value

--000e0ce0d6364e18d104818db8be
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 11, 2010 at 4:57 PM, George Langley wrote:

> Hi all. Is there an issue with $_GET not handling a Base64-encoded
> value correctly? (PHP is 5.1.6)
> Am receiving a Base64-encoded value:
>
> theurl.com/index.php?message=xxxxx
>
> and retrieving it with $_GET:
>
> echo $_GET["message"];
>
> xxxxx is a Japanese phrase, that has been encoded into Base64. So is using
> the + symbol:
>
> ...OODq+OCou...
>
> but my $_GET is replacing the + with a space:
>
> ...OODq OCou...
>
> thus the base64_decode() is failing (displays diamonds with questions marks
> on my Mac).
>
> The Base64-encoded string is 156 characters long, if that has any
> bearing. My test URL is 230 characters in total, less than the "old" 256
> limit.
> All I can find online is a reference that PHP will no longer assume
> that a space is a +:
>
>
>
> but my problem is the opposite - the + symbols are there, but the GET is
> removing them.
> (And to add a wrinkle, this then goes into a Joomla! page, whose
> getVar() command completely removes the +, so I couldn't even do a string
> replace, as I don't know where the + should have been!)
>
> Tired of looking at the dark red spot on the wall! Thanks.
>
>
> George Langley Multimedia Developer Audio/Video Editor Musician,
> Arranger, Composer www.georgelangley.ca
>
>
>
Get variables are automatically urldecoded:
http://php.net/manual/en/function.urldecode.php

The '+' character is one of the special characters automatically decoded
(normally signifies a space.) I would try using an encoding scheme that
doen't have collisions with special URL characters, use a different global
array not automatically decoded (POST, SESSION), or cautiously urlencode the
url's '+' chars (string replace all spaces to +) and then perform the base
64 decoding.

--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com

--000e0ce0d6364e18d104818db8be--

Re: $_GET is Mangling Base64 value

On Thu, Mar 11, 2010 at 22:57, George Langley wrot=
e:
>        Hi all. Is there an issue with $_GET not handl=
ing a Base64-encoded value correctly? (PHP is 5.1.6)
>        Am receiving a Base64-encoded value:
>
> theurl.com/index.php?message=3Dxxxxx
>
>  and retrieving it with $_GET:
>
> echo $_GET["message"];
>
> xxxxx is a Japanese phrase, that has been encoded into Base64. So is usin=
g the + symbol:
>
> ...OODq+OCou...
>
> but my $_GET is replacing the + with a space:
>
> ...OODq OCou...
>
> thus the base64_decode() is failing (displays diamonds with question=
s marks on my Mac).
>
>        The Base64-encoded string is 156 characte=
rs long, if that has any bearing. My test URL is 230 characters in total, l=
ess than the "old" 256 limit.
>        All I can find online is a reference that PHP =
will no longer assume that a space is a +:
>
>
>
> but my problem is the opposite - the + symbols are there, but the GET is =
removing them.
>        (And to add a wrinkle, this then goes into a J=
oomla! page, whose getVar() command completely removes the +, so I couldn't=
even do a string replace, as I don't know where the + should have been!)
>
>        Tired of looking at the dark red spot on the w=
all! Thanks.

PHP does a urldecode() on GET parameters, which regards + as a space.
You should be able to get the information you need using
$_SERVER['QUERY_STRING'].

--=20
Daniel Egeberg

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: $_GET is Mangling Base64 value

On Thu, Mar 11, 2010 at 23:16, Daniel Egeberg wrote:
> On Thu, Mar 11, 2010 at 22:57, George Langley wr=
ote:
>>        Hi all. Is there an issue with $_GET not hand=
ling a Base64-encoded value correctly? (PHP is 5.1.6)
>>        Am receiving a Base64-encoded value:
>>
>> theurl.com/index.php?message=3Dxxxxx
>>
>>  and retrieving it with $_GET:
>>
>> echo $_GET["message"];
>>
>> xxxxx is a Japanese phrase, that has been encoded into Base64. So is usi=
ng the + symbol:
>>
>> ...OODq+OCou...
>>
>> but my $_GET is replacing the + with a space:
>>
>> ...OODq OCou...
>>
>> thus the base64_decode() is failing (displays diamonds with questio=
ns marks on my Mac).
>>
>>        The Base64-encoded string is 156 charact=
ers long, if that has any bearing. My test URL is 230 characters in total, =
less than the "old" 256 limit.
>>        All I can find online is a reference that PHP=
will no longer assume that a space is a +:
>>
>>
>>
>> but my problem is the opposite - the + symbols are there, but the GET is=
removing them.
>>        (And to add a wrinkle, this then goes into a =
Joomla! page, whose getVar() command completely removes the +, so I couldn'=
t even do a string replace, as I don't know where the + should have been!)
>>
>>        Tired of looking at the dark red spot on the =
wall! Thanks.
>
> PHP does a urldecode() on GET parameters, which regards + as a space.
> You should be able to get the information you need using
> $_SERVER['QUERY_STRING'].
>

And this is now made a bit clearer in the manual:
http://svn.php.net/viewvc?view=3Drevision&revision=3D296092

Should propagate to the mirrors some time tomorrow.

--=20
Daniel Egeberg

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: $_GET is Mangling Base64 value

--=-wPC3AL1tBg0vsLN1vLlU
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-03-11 at 17:34 -0700, George Langley wrote:

> Hi again. Thanks for all the info!
> Not sure I'd agree that GET should just "assume" it was URLencoded, but hey - who am I to argue? :-{)]
> As mentioned, this is eventually buried into a Joomla! site's login functions (displays any errors). So not sure I'd have access to the originating call to URLencode it before sending, if it's part of the standard Joomla! login function and not some of our custom code.
> However, Mike's suggestion to "pre-parse" it at our end:
>
> $_GET['foo'] = str_replace(' ', '+', $_GET['foo']);
>
> appears to work fine. I put the above in in just before the GET in my bare-bones PHP-only test, and in the actual Joomla! page just before their equivalent call:
>
> echo base64_decode(JRequest::getVar('message', '', 'method', 'base64'));
>
> Have tested it with strings that also included a / (being the other non-alphanumeric character that Base64 uses), and it remains unaffected.
> So, guess I can either add the pre-parse wherever I need to, or try to locate the call to see if I can urlencode it (and who am I to argue why they didn't do that too?!)
> Thanks again.
>
> George


Of course GET data would be assumed to be url encoded, it's part of the
URL, what other format could it take?! :p

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-wPC3AL1tBg0vsLN1vLlU--

Re: $_GET is Mangling Base64 value

----9315620d98ce37cf23f7a
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi again Thanks for all the info!
Not sure I=27d agree that GET should just =22assume=22 it was URLencode=
d=2C but hey - who am I to argue=3F  :-=7B)=5D
As mentioned=2C this is eventually buried into a Joomla! site=27s login=
functions (displays any errors) So not sure I=27d have access to the=
originating call to URLencode it before sending=2C if it=27s part of th=
e standard Joomla! login function and not some of our custom code
However=2C Mike=27s suggestion to =22pre-parse=22 it at our end=3A

$_GET['foo'] =3D str=5Freplace(=27 ', =27+', $_G=
ET['foo'])=3B

appears to work fine I put the above in in just before the GET in my =
bare-bones PHP-only test=2C and in the actual Joomla! page just before t=
heir equivalent call=3A

echo base64=5Fdecode(JRequest::getVar(=27message', ''=2C =27=
method', =27base64=27))=3B

Have tested it with strings that also included a / (being the other non=
-alphanumeric character that Base64 uses)=2C and it remains unaffected=

So=2C guess I can either add the pre-parse wherever I need to=2C or try=
to locate the call to see if I can urlencode it (and who am I to argue =
why they didn=27t do that too=3F!)
Thanks again

George

----9315620d98ce37cf23f7a--