RE: [PHP] base64_encode, forward slashes and mod_rewrite
There are variants of base64, which replace the + / characters with something less likely to cause problems. http://en.wikipedia.org/wiki/Base64 Jared sorry Ive done it again, for anyones interest, you might have to urlencode the string twice for mod_rewrite to accept encrypted and base64_encoded strings which add slashes and ampersands into their strings. It is confirmed there is a bug in mod_rewrite and doesnt like the urlencoded %2F characters. On 24/02/2006, at 10:31 AM, Dan Rossi wrote: Continueing on my prior problem, Ive discovered that base64_encode adds forward slashes in its encoded string, when its urlencoded it becomes something like /feeds/UmFuZG9tSVZd%2FMChU7sMQqdUi%2FrgYHD7 mod_rewrite doesnt seem to like the %2F in the string and fails with a 404 as it doesnt get a match using RewriteRule ^feeds/(.*)$ /refer.php?$1 [L,NE] What should i do ? Should i replace the / with a different character then convert it back later ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] base64_encode, forward slashes and mod_rewrite
Continueing on my prior problem, Ive discovered that base64_encode adds forward slashes in its encoded string, when its urlencoded it becomes something like /feeds/UmFuZG9tSVZd%2FMChU7sMQqdUi%2FrgYHD7 mod_rewrite doesnt seem to like the %2F in the string and fails with a 404 as it doesnt get a match using RewriteRule ^feeds/(.*)$ /refer.php?$1 [L,NE] What should i do ? Should i replace the / with a different character then convert it back later ?
Re: [PHP] base64_encode, forward slashes and mod_rewrite
sorry Ive done it again, for anyones interest, you might have to urlencode the string twice for mod_rewrite to accept encrypted and base64_encoded strings which add slashes and ampersands into their strings. It is confirmed there is a bug in mod_rewrite and doesnt like the urlencoded %2F characters. On 24/02/2006, at 10:31 AM, Dan Rossi wrote: Continueing on my prior problem, Ive discovered that base64_encode adds forward slashes in its encoded string, when its urlencoded it becomes something like /feeds/UmFuZG9tSVZd%2FMChU7sMQqdUi%2FrgYHD7 mod_rewrite doesnt seem to like the %2F in the string and fails with a 404 as it doesnt get a match using RewriteRule ^feeds/(.*)$ /refer.php?$1 [L,NE] What should i do ? Should i replace the / with a different character then convert it back later ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] base64_encode in URLs
On Tue, May 10, 2005 8:50 pm, Joe Harman said: Hey just curious if it's okay to encode variables that are passed in URLs with base64_encode??? since, I am going to pass a email address in the URL, I would like to protect the email address from typical people I dunno if every character that can be output by base64_encode is URL-safe or not, but you could do: urlencode(base64_encode($email)) and be 100% certain that it is safe, and that the data you want will come through. That said, I don't think base64_encode will offer much protection from humans who want to snag emails, and you presumably aren't listing these URLs somewhere for web-bot harvesters to find... Though that would fool them, at least in the present. ARAIK, almost *any* obfuscation of email addresses foils the harvest bots. This seems unbelievable, but I liken it to fishing: If every time you cast a line in the water, you come up with a million fish, how hard will you work to change your bait? That is the current state of affairs in the arms race of email harvesting -- The spammers have SO MANY fish biting that they simply don't need to bypass obfuscation. Sooner or later, however, that will change, especially if the harvesters ever care about quality of their fish. While I'm not running around fixing all my old obfuscation code, I'm pretty much not using email obfuscation on any new sites/code. Instead, I build a FORM that will send the email blind to the recipient, and have a throttle choke that limits a given IP ($_SERVER['REMOTE_ADDR']) to N emails sent in H hours. Certainly, a script could be written to re-connect and get a new IP, but that in itself would take enough time on the end of the spammer that I doubt they'll want to bother any time soon. And it's all wrapped up in a 'spaminator' function that I can replace with something more robust if I need to. I figure this way, I'm 2 steps ahead in this arms race, so when the bad guys start decoding the obfuscation emails, I'll be ready for 'em. Now if I could just figure out a way to get my OWN email out of their lists so I wasn't getting 10,000 spams per day (literally) I'd be a Happy Camper. -- 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
Re: [PHP] base64_encode in URLs
HA... Thanks for your thoughts... I am actually using this for a broadcast email system... I just use a PHP image generator to make a 1 x1 gif... the image generator script takes a variable for color then I added another one for email address to keep stats on who has opened the message ex. image_script.php?color=00[EMAIL PROTECTED] but I am using base64_encode to encode the email address and call the variable something besides email... I suppose i didn't have to do this, but thought it would be a good practice to do it... the end result looks something like this : image_script.php?color=00key=jtzOjM6IkpvZSI7czo5OiJsYXN0X2 also this is embedded in the body of an HTML email... so, i think it's pretty safe any how the script just updates the stats and returns a 1x1 gif... Cheers! Joe On 5/11/05, Richard Lynch [EMAIL PROTECTED] wrote: On Tue, May 10, 2005 8:50 pm, Joe Harman said: Hey just curious if it's okay to encode variables that are passed in URLs with base64_encode??? since, I am going to pass a email address in the URL, I would like to protect the email address from typical people I dunno if every character that can be output by base64_encode is URL-safe or not, but you could do: urlencode(base64_encode($email)) and be 100% certain that it is safe, and that the data you want will come through. That said, I don't think base64_encode will offer much protection from humans who want to snag emails, and you presumably aren't listing these URLs somewhere for web-bot harvesters to find... Though that would fool them, at least in the present. ARAIK, almost *any* obfuscation of email addresses foils the harvest bots. This seems unbelievable, but I liken it to fishing: If every time you cast a line in the water, you come up with a million fish, how hard will you work to change your bait? That is the current state of affairs in the arms race of email harvesting -- The spammers have SO MANY fish biting that they simply don't need to bypass obfuscation. Sooner or later, however, that will change, especially if the harvesters ever care about quality of their fish. While I'm not running around fixing all my old obfuscation code, I'm pretty much not using email obfuscation on any new sites/code. Instead, I build a FORM that will send the email blind to the recipient, and have a throttle choke that limits a given IP ($_SERVER['REMOTE_ADDR']) to N emails sent in H hours. Certainly, a script could be written to re-connect and get a new IP, but that in itself would take enough time on the end of the spammer that I doubt they'll want to bother any time soon. And it's all wrapped up in a 'spaminator' function that I can replace with something more robust if I need to. I figure this way, I'm 2 steps ahead in this arms race, so when the bad guys start decoding the obfuscation emails, I'll be ready for 'em. Now if I could just figure out a way to get my OWN email out of their lists so I wasn't getting 10,000 spams per day (literally) I'd be a Happy Camper. -- Like Music? http://l-i-e.com/artists.htm -- Joe Harman - Do not go where the path may lead, go instead where there is no path and leave a trail. - Ralph Waldo Emerson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] base64_encode in URLs
Joe, this may be a little off topic, but most modern email clients wont show images in HTML unless the user clicks to show images manually. This could fool your automatic counting and email verification. On 5/11/05, Joe Harman [EMAIL PROTECTED] wrote: HA... Thanks for your thoughts... I am actually using this for a broadcast email system... I just use a PHP image generator to make a 1 x1 gif... the image generator script takes a variable for color then I added another one for email address to keep stats on who has opened the message ex. image_script.php?color=00[EMAIL PROTECTED] but I am using base64_encode to encode the email address and call the variable something besides email... I suppose i didn't have to do this, but thought it would be a good practice to do it... the end result looks something like this : image_script.php?color=00key=jtzOjM6IkpvZSI7czo5OiJsYXN0X2 also this is embedded in the body of an HTML email... so, i think it's pretty safe any how the script just updates the stats and returns a 1x1 gif... Cheers! Joe On 5/11/05, Richard Lynch [EMAIL PROTECTED] wrote: On Tue, May 10, 2005 8:50 pm, Joe Harman said: Hey just curious if it's okay to encode variables that are passed in URLs with base64_encode??? since, I am going to pass a email address in the URL, I would like to protect the email address from typical people I dunno if every character that can be output by base64_encode is URL-safe or not, but you could do: urlencode(base64_encode($email)) and be 100% certain that it is safe, and that the data you want will come through. That said, I don't think base64_encode will offer much protection from humans who want to snag emails, and you presumably aren't listing these URLs somewhere for web-bot harvesters to find... Though that would fool them, at least in the present. ARAIK, almost *any* obfuscation of email addresses foils the harvest bots. This seems unbelievable, but I liken it to fishing: If every time you cast a line in the water, you come up with a million fish, how hard will you work to change your bait? That is the current state of affairs in the arms race of email harvesting -- The spammers have SO MANY fish biting that they simply don't need to bypass obfuscation. Sooner or later, however, that will change, especially if the harvesters ever care about quality of their fish. While I'm not running around fixing all my old obfuscation code, I'm pretty much not using email obfuscation on any new sites/code. Instead, I build a FORM that will send the email blind to the recipient, and have a throttle choke that limits a given IP ($_SERVER['REMOTE_ADDR']) to N emails sent in H hours. Certainly, a script could be written to re-connect and get a new IP, but that in itself would take enough time on the end of the spammer that I doubt they'll want to bother any time soon. And it's all wrapped up in a 'spaminator' function that I can replace with something more robust if I need to. I figure this way, I'm 2 steps ahead in this arms race, so when the bad guys start decoding the obfuscation emails, I'll be ready for 'em. Now if I could just figure out a way to get my OWN email out of their lists so I wasn't getting 10,000 spams per day (literally) I'd be a Happy Camper. -- Like Music? http://l-i-e.com/artists.htm -- Joe Harman - Do not go where the path may lead, go instead where there is no path and leave a trail. - Ralph Waldo Emerson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] base64_encode in URLs
Hey Thanks Brandon... I know that does happen, so the stats is just suppose to approximate.. thanks for point that out Cheers Joe On 5/11/05, Brandon Ryan [EMAIL PROTECTED] wrote: Joe, this may be a little off topic, but most modern email clients wont show images in HTML unless the user clicks to show images manually. This could fool your automatic counting and email verification. On 5/11/05, Joe Harman [EMAIL PROTECTED] wrote: HA... Thanks for your thoughts... I am actually using this for a broadcast email system... I just use a PHP image generator to make a 1 x1 gif... the image generator script takes a variable for color then I added another one for email address to keep stats on who has opened the message ex. image_script.php?color=00[EMAIL PROTECTED] but I am using base64_encode to encode the email address and call the variable something besides email... I suppose i didn't have to do this, but thought it would be a good practice to do it... the end result looks something like this : image_script.php?color=00key=jtzOjM6IkpvZSI7czo5OiJsYXN0X2 also this is embedded in the body of an HTML email... so, i think it's pretty safe any how the script just updates the stats and returns a 1x1 gif... Cheers! Joe On 5/11/05, Richard Lynch [EMAIL PROTECTED] wrote: On Tue, May 10, 2005 8:50 pm, Joe Harman said: Hey just curious if it's okay to encode variables that are passed in URLs with base64_encode??? since, I am going to pass a email address in the URL, I would like to protect the email address from typical people I dunno if every character that can be output by base64_encode is URL-safe or not, but you could do: urlencode(base64_encode($email)) and be 100% certain that it is safe, and that the data you want will come through. That said, I don't think base64_encode will offer much protection from humans who want to snag emails, and you presumably aren't listing these URLs somewhere for web-bot harvesters to find... Though that would fool them, at least in the present. ARAIK, almost *any* obfuscation of email addresses foils the harvest bots. This seems unbelievable, but I liken it to fishing: If every time you cast a line in the water, you come up with a million fish, how hard will you work to change your bait? That is the current state of affairs in the arms race of email harvesting -- The spammers have SO MANY fish biting that they simply don't need to bypass obfuscation. Sooner or later, however, that will change, especially if the harvesters ever care about quality of their fish. While I'm not running around fixing all my old obfuscation code, I'm pretty much not using email obfuscation on any new sites/code. Instead, I build a FORM that will send the email blind to the recipient, and have a throttle choke that limits a given IP ($_SERVER['REMOTE_ADDR']) to N emails sent in H hours. Certainly, a script could be written to re-connect and get a new IP, but that in itself would take enough time on the end of the spammer that I doubt they'll want to bother any time soon. And it's all wrapped up in a 'spaminator' function that I can replace with something more robust if I need to. I figure this way, I'm 2 steps ahead in this arms race, so when the bad guys start decoding the obfuscation emails, I'll be ready for 'em. Now if I could just figure out a way to get my OWN email out of their lists so I wasn't getting 10,000 spams per day (literally) I'd be a Happy Camper. -- Like Music? http://l-i-e.com/artists.htm -- Joe Harman - Do not go where the path may lead, go instead where there is no path and leave a trail. - Ralph Waldo Emerson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Joe Harman - Do not go where the path may lead, go instead where there is no path and leave a trail. - Ralph Waldo Emerson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] base64_encode in URLs
Hey just curious if it's okay to encode variables that are passed in URLs with base64_encode??? since, I am going to pass a email address in the URL, I would like to protect the email address from typical people -- Joe Harman - Do not go where the path may lead, go instead where there is no path and leave a trail. - Ralph Waldo Emerson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] base64_encode corrupts files?
Hi, I trying to send a binary file (exe, zip, etc etc) that is attached using mail() function. I'm do a base64_encode and chunk_split after read the file, but the result is a corrupt file so i can't read the attached file with my mail client. When i call the script the attached file is corrupt. My server is Red Hat Linux 7.3, Apache 1.3.27-2, PHP 4.1.2 Any idea? Please Help. This is my chunk of code. ?php // create a MIME boundary string $boundary = =. . md5(uniqid(time())) . =; // add MIME data to the message headers $headers .= MIME-Version:1.0\r\n; $headers .= Content-Type: multipart/mixed;\r\n\tboundary=\$boundary\\r\n\r\n; // start building a MIME message $str =This is a multi-part message in MIME format.\n; $str .= -- . $boundary . \r\n; $str .= Content-Type: text/plain;\r\n\tcharset=\us-ascii\\r\n; $str .= Content-Transfer-Encoding: 7bit\r\n\r\n; $str .= Hi all.\r\n\r\n; //attach:w $str .= --.$boundary.\n; $file=mapa.zip; $str .=Content-Type: application/octet-stream; name=\.$file.\\n; $str .=Content-Transfer-Encoding: base64\n; $str .=Content-Disposition: attachment; filename=\.$file.\\n\n; $fd=fopen ($file, rb); $FileContent=fread($fd,filesize($file)); fclose ($fd); $FileContent=chunk_split(base64_encode($FileContent)); $str .=$FileContent; //attach ends $body=$str; //send mail mail([EMAIL PROTECTED], I am really desperated, $body, $headers); ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] base64_encode
Hi, RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies para 6.8 Base64 Content-Transfer-Encoding URL:ftp://ftp.ntua.gr/pub/docs/rfc/20xx/2045 or your favorite RFC repository -Stathis. Gerard Samuel wrote: Thanks Andrew Braund wrote: Googling on ascii table base64 got me; http://ulla.mcgill.ca/arts150a/sample_exam.htm a nice little table with the base 64 characters (also got http://email.about.com/library/weekly/aa070201a.htm which discribes base64) So in answer to your question the extras look like + and /. 26+26+10+2=64 sounds right. HTH Andrew Braund -Original Message- From: Gerard Samuel [mailto:[EMAIL PROTECTED]] Sent: Thursday, 27 June 2002 11:15 To: php-gen Subject: [PHP] base64_encode What other characters are possible from the output of base64_encode() except [A-Za-z0-9] ?? Thanks -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Rouvas Stathis [EMAIL PROTECTED] http://www.di.uoa.gr/~rouvas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] base64_encode
What other characters are possible from the output of base64_encode() except [A-Za-z0-9] ?? Thanks -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] base64_encode
Googling on ascii table base64 got me; http://ulla.mcgill.ca/arts150a/sample_exam.htm a nice little table with the base 64 characters (also got http://email.about.com/library/weekly/aa070201a.htm which discribes base64) So in answer to your question the extras look like + and /. 26+26+10+2=64 sounds right. HTH Andrew Braund -Original Message- From: Gerard Samuel [mailto:[EMAIL PROTECTED]] Sent: Thursday, 27 June 2002 11:15 To: php-gen Subject: [PHP] base64_encode What other characters are possible from the output of base64_encode() except [A-Za-z0-9] ?? Thanks -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] base64_encode
Thanks Andrew Braund wrote: Googling on ascii table base64 got me; http://ulla.mcgill.ca/arts150a/sample_exam.htm a nice little table with the base 64 characters (also got http://email.about.com/library/weekly/aa070201a.htm which discribes base64) So in answer to your question the extras look like + and /. 26+26+10+2=64 sounds right. HTH Andrew Braund -Original Message- From: Gerard Samuel [mailto:[EMAIL PROTECTED]] Sent: Thursday, 27 June 2002 11:15 To: php-gen Subject: [PHP] base64_encode What other characters are possible from the output of base64_encode() except [A-Za-z0-9] ?? Thanks -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Gerard Samuel http://www.trini0.org:81/ http://dev.trini0.org:81/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] base64_encode problem while using IMAP
I've been trying to decode an attached image in an email using imap. Parse error: parse error, expecting `T_VARIABLE' or `'$'' in imapTest.php on line 80 $image = trim(@imap_fetchbody($mbox, 2, 2)); $64image = base64_encode($image); I've also tried: $image = trim(@imap_fetchbody($mbox, 2, 2)); $64image = imap_base64($image); Can someone tell me what I'm missing? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
