I have a php problem I hope someone can help me solve. This syntax:
$TheEmail=chr(34) . $POST[newname] . chr(34) . " < " . $POST['newemail'] . ">";
echo($TheEmail);
will display as in:
"Admin Tester" < Tester7@mydomain.com>
But this syntax:
$TheEmail=chr(34) . $POST[newname] . chr(34) . " <" . $POST['newemail'] . ">";
will only display truncated as:
"Admin Tester"
I need to get rid of the space character following the < character, without getting truncation. Possible?
halojoy;10937954 wrote:<word> is used to indicate one HTML-tag
this is why it can cause troubles.The solution is to use [man]htmlspecialchars/man when displaying critical stuff.
Especially strings with < and >try this:
echo htmlspecialchars($TheEmail);
Wow, spot on! I spent around 20 hours on Google trying to find out why I could not escape the < character in that example before I asked for help. When I tried your way I learned that it was not that the $TheEmail variable didn't properly contain the entire string, untruncated beyond that < character, but it was the operation I was trying to do (such as echo) that was evaluating the character as an operator upon the terms to its right. I mean, $TheMail var really was a literal string after all and it was the way I was trying to use it causing the problem. PHP can be tricky! Thanks very much for your reply, it resolved the issue.
Nice way to end 2009! Happy New Year to you, and to all. 
Huh? In the code you originally posted
$TheEmail=chr(34) . $_POST[newname] . chr(34) . " <" . $_POST['newemail'] . ">";The only literal strings are the bits displayed here in red. $TheEmail is a variable containing a string, and echo simply outputs that string. The only PHP operators being used here at all are string concatenation and assignment.
As halojoy said, "<tester@example.com>" would be interpreted by the HTML parser as an unrecognised tag and would ignore it. "< tester@example.com>" displays because it's not interpreted as a tag (because the "<" is not immediately followed by the tag name). That is why [man]htmlspecialchars[/man] is needed to display a string in HTML without any part of it being treated as special HTML characters.
I'll have to go into some detail so others can reproduce this issue that I thought was resolved. Basically, a page has a form that gets filled in with a name and email address. Both of those fields are to be used to send authenticated SMTP email per the example given at http://www.phpmaniac.net/wiki/index.php/Pear_Mail#Sending_using_authenticated_SMTP (this same example is actually all over the web).
I sometimes get email where the email client (OE in my case) will display the To column as a name such as, just for example, "Site Admin" instead of something like "username@mydomain.com". In other words, if you look at the header of the email message properties you'd exactly see:
To: Site Admin <username@mydomain.com>
and the same thing can occur with the email From header as in:
From: My Emailer <username@mydomain.com>
Anyway, based on that Pear Mail example shown at the above link I used a slight modificatin of it in this way to build email headers:
// Constructing the email
$sender = "myaccount@mydomain.com";
$from = "This Application <myaccount@mydomain.com>";
$replyto = "forsorting@mydomain.com";
// $recipient=htmlspecialchars($POST[newname]." <".$POST['newemail'].">");
$TheEmail=$_POST['newemail'];
$recipient = "$TheEmail";
$subject = "Your Login information.";
$text = "$TheText";
$html = $TheHTML;
...
$headers = array(
'Sender' => $sender,
'Return-Path' => $sender,
'Reply-To' => $replyto,
'From' => $from,
'Subject' => $subject,
'To' => $recipient
);
It works fine, when I receive the test email in the client the From header shows in message properties as:
This Application <myaccount@mydomain.com>
But here's where the problem comes in. Notice that in my code I had to comment out one way of sending the $recipient header. That's because if I use it instead of using the way I do it as shown, I'll get a validation error from the email server being connectd to. Even though the commented out section for $recipient will echo with the proper looking fomat as in:
User Name <useraccount@userdomain.com>
it just will not validate (so says the server). However, if I simply put the same exact text manually in normal quotes:
$recipient="User Name <useraccount@userdomain.com>";
as I similarly do it in the $from variable, it doesn't have any validation problem! But, these 2 values must be computed, it cannot be static like that.
I thought the "htmlspecialchars" parameter would get rid of this issue, since it does echo exactly like what I put in quotes manually, but it isn't. Somehow it seems to be passing non prinatble characters to the email server regardless. I know this problem is occcuring because of the < character immediately to the left of the $_POST['newemail'] variable, but I don't know how to overcome this problem.
I don't know exactly what causes the problem, but I suspect it's in the way PHP is handing off the computed string to the $recipient variable. I'm asking if someone can duplicate this too (requires install of Pear Mail on your server) and determine where the problem lies. Is it a bug? Is there a workaround? Is my fairly new exposure to properly using PHP at fault? I'm wrongly using htmlspecialchars?
(I wanted to mark this thread unresolved, but I cannot. I previously thought it was resolved.)
RGM wrote:Even though the commented out section for $recipient will echo with the proper looking fomat as in:
User Name <useraccount@userdomain.com>
No it won't. It'll be this:
User Name <useraccount@userdomain.com>RGM wrote:I thought the "htmlspecialchars" parameter would get rid of this issue, since it does echo exactly like what I put in quotes manually
Again, no it doesn't - see above comment.
RGM wrote:I'm wrongly using htmlspecialchars?
Yup.
If you want to display <email> via HTML, then yes, htmlspecialchars() is needed so that the browser doesn't interpret the recipient string as having any HTML tags. If you want to send an email, htmlspecialchars() is not needed because you don't want "<" or ">" - you want a literal "<" or ">" respectively.
RGM wrote:(I wanted to mark this thread unresolved, but I cannot. I previously thought it was resolved.)
Although I suspect the issue is now resolved after my explanation above, I've unmarked the thread as resolved for you.
bradgrafelman;10938123 wrote:No it won't. It'll be this:
User Name [COLOR="Red"]<[/COLOR]useraccount@userdomain.com[COLOR="red"]>[/COLOR]Aha, yes, that I understand. No wonder the server objects.:eek:
So, I'm back to square 1 again, then. How do I pass this to the server? Because the answer to my 1st post opening this topic isn't applicable that I can see. I need to do the equivalent of this:
$TheEmail=$POST[newname] . " <" . $POST['newemail'] . ">";
to pass to the server. Yes, I need < to be a literal, but it must be in the string immediately to the left of the $ character, but if it is then $TheEmail gets truncated and the server complains about validation.
My apology for being dense, I honestly don't yet understand how to do this.
RGM wrote:How do I pass this to the server?
What do you mean pass it to the server? What server?
This is kludge, but it worked! The last post to me got me to thinking...
$recipient=htmlspecialchars($POST[newname] . " <" . $POST['newemail'] . ">"); // < to < and > to >
$recipient=str_replace("<","<",$recipient); // < to <
$recipient=str_replace(">",">",$recipient); // > to >
Is there a way to do it in 1 statement, though? As I said, this will result in $recipient getting truncated or in any case at least the email server complaining about validation:
$recipient=$POST[newname] . " <" . $POST['newemail'] . ">";
Since my test email this time came with proper headers, I'm again marking this topic I opened as resolved. MUCH thanks to all the help! Still looking for a better syntax method, though, as my kludge seems to be, well, a kludge.
RGM wrote:Is there a way to do it in 1 statement, though?
Yes...
$recipient = "\"$_POST['newname']\" <$_POST[newemail]>";Why are you even using htmlspecialchars() at all?
EDIT: Actually, to prevent the user from injecting malicious e-mail headers, you should probably do something like:
$recipient = '"' . str_replace(array('"', "\n", "\r"), array('\\"', '', ''), $_POST['newname']) . "<$_POST[newemail]>";as well as validating $_POST['newemail'] against some form of e-mail address validator (e.g. a regexp pattern).
bradgrafelman;10938134 wrote:Yes...
$recipient = "\"$_POST['newname']\" <$_POST[newemail]>";Why are you even using htmlspecialchars() at all?
EDIT: Actually, to prevent the user from injecting malicious e-mail headers, you should probably do something like:
$recipient = '"' . str_replace(array('"', "\n", "\r"), array('\\"', '', ''), $_POST['newname']) . "<$_POST[newemail]>";as well as validating $_POST['newemail'] against some form of e-mail address validator (e.g. a regexp pattern).
Oh, nice! I'll try that. To answer your question, though, I was using it because it was suggested in this topic for me to try, but I didn't realize the < and > were being replaced with html tags (which I didn't want). My bad, I didn't explain my need properly.
The 2nd part of my answer is I'm good at html & vb/vbscript but had to move to a Linux/Apache server, kicking & screaming because I knew I'd have to learn PHP and Ajax and although I'm half decent with javascript, I've only been at this PHP/Ajax stuff a month so I'm very much a noobie in that way. Knowing a bit more than some js helps, though. I don't have months to learn, I'm on a commercial project (of my own) that seriously needs completion before I can no longer do so. If you want and if the board rules allow it I'll pm the link to you, of course I don't want to advertise it - out of forum courtesy (not to mention the fact that it's in early development stage). I tried doing online stores, but they flopped badly so now I'm converting an old visual basic program I wrote 10 years ago, and which electronic engineering departments loved at the time (until Microsoft disabled the graphing util of theirs I was using), to a web based version. I'm fairly sure some companies around the world will subscribe to sections of it, but which also has sections free to use. It's an engineering design aid system and nothing like it exists on or off the web. Now I can concentrate on it again, instead of worrying with that new user registration issue involving email! Most all I have to do now just uses Ajax or normal js, and some is done already.
RGM wrote:I was using it because it was suggested in this topic for me to try
It was suggested because you were talking about displaying the value, not using it in a mail() command.
Your original problem could have been fixed by adding this to your PHP script instead:
header('Content-Type: text/plain');preventing the browser from rendering the <>'s as HTML code and instead just displaying them.
bradgrafelman;10938165 wrote:It was suggested because you were talking about displaying the value, not using it in a mail() command.
Your original problem could have been fixed by adding this to your PHP script instead:
header('Content-Type: text/plain');preventing the browser from rendering the <>'s as HTML code and instead just displaying them.
Yes, you're entirely correct and your reply was proper in the context offered, and appreciated. My bad and I apologize for the confusion I introduced regarding what I really wanted to do with the computed variable. Too much brevity in my post was my 1st error, and not seeing the forest for the trees was my 2nd error (meaning I wasn't even thinking about html parsing at all, but how could anyone reading my post have known that?)
What really happened, that led to my topic opening post, was that I was confused by and concentating on the fact that the email server was complaining about a validation error. When I echo'd the string to see why, I wasn't thinking about html parsing whatsoever, which compounded the problem. Two wrongs don't lead to a right, eh?:queasy: I've not done it yet, but I think PHP can write a file to my area of the html server and if so then that would have been the better way to see what really was going to the email server (I could have viewed that file via my ftp program). I didn't think to do try that, and at this writing I'm not sure I really can write a file for later viewing by ftp.:o
Can't edit my previous post, so continuing here.
I'm wondering, if I'd have used that header would it not have kept my form in that same page from working and from creating the variable I was having problems with? To duplicate the problem syntax, didn't I have to pull the $POST variables from a form? Doesn't the $POST operative only look at a currently loaded page?
Also, I ommitted mentioning that I'm aware that even if PHP can write a file on the html server, I'd need to set temporary permission for it to do so.
Not that any of this excuses my lack of having made clear in my opening post what I was really trying to do...
RGM wrote:I'm wondering, if I'd have used that header would it not have kept my form in that same page from working
If the header wasn't placed in a conditional statement that was only executed once the form was submitted, then yes, the form would just be displayed as plain text rather than parsed as HTML.
Really, the best solution would have just been to view the source of the page in your browser rather than looking at the rendered content.
I should point out that to others who might get to a post in this topic, someway other than having read it from its beginning, that the pesky < character issue of this topic has been resolved by others more knowledgeable than me! So my questions are academic at this point, in pursuit of tidbits.
I don't remember looking at the source code, probably because IE didn't report an error on the page (it's normal for me in designing to pay attention for that indicator). So yes, I've no way to say that might not have shed light on the problem.
Still, sending to the email server:
$recipient=($POST[newname] . " <" . $POST['newemail'] . ">");
does result in my email server complaining about validation. I don't know why but it certainly doesn't work, and I know that the < character cannot be escaped.
But this line:
$recipient=($POST[newname] . " < " . $POST['newemail'] . ">");
doesn't email server validate because of the space that follows the < character.
Considering that $recipient is being sent ONLY to the email server, that still seems weird to me. I only sent it to the browser during troubleshooting when both methods failed (and thus improperly ended up assuming $recipient was being truncated). Maybe looking at the source code when sending it to the browser might have show interesting stuff about $recipient; but not completely why those 2 above methods fail with the email server, nor how to fix it.
While this isn't the best way to do it, this kludge makes the email server happy:
$recipient=htmlspecialchars($POST[newname] . " <" . $POST['newemail'] . ">");
$recipient=str_replace("<","<",$recipient);
$recipient=str_replace(">",">",$recipient);
I'm still confused why, with no send to a browser involved, that kludge works but
$recipient=($POST[newname] . " <" . $POST['newemail'] . ">");
does not. The email server error is independent of trying to display the computed variable in a browser. No browser type parsing should be involved when sending it to the email server, should it? I just don't understand why yet.