Jump to content
  • Checkout
  • Login
  • Get in touch


The e-commerce.

Password_Reset.php $HTTP_GET_VARS removed @ symbol


Recommended Posts

I upgraded from 2.2RC2a to 2.3.3 and have completed what looks like all the changes without issue, except one.

The password_reset.php file reads the "account" variable from the URL that was clicked on during the password forgotten stage.

The code of password_reset.php converts the URL "account" to a string:


$email_address = tep_db_prepare_input($HTTP_GET_VARS['account']);


Then this new string is passed to the validation.php file as tep_validate_email:


if ( (strlen($email_address) < ENTRY_EMAIL_ADDRESS_MIN_LENGTH) || (tep_validate_email($email_address) == false) ) {


I always get a FALSE because the $HTTP_GET_VARS['account'] converts the URL account key from "myemail%40gmail.com" to "myemailgmail.com"

The URLENCODED @ symbol "%40" is removed.


Why does the $HTTP_GET_VARS command remove this @ symbol?

Link to comment
Share on other sites

It seems more likely that




is less than




because the latter has been given too high a value. It is set as we know in


admin > Configuration > Minimum Values > E-mail Address


$HTTP_GET_VARS isn't a command, and it doesn't remove anything. It is an array.

Link to comment
Share on other sites

tep_db_prepare_input() appears to be stripping '@' (or perhaps any %nn character) out of the email string in $HTTP_GET_VARS['account']. You would have to confirm that $HTTP_GET_VARS['account'] still has the '@' in it at that point, though, before casting blame on tep_db_prepare_input(). Then check if $email_address has in fact lost the '@' or '%40'. If it is tep_db_prepare_input() that's the offender, is that the proper routine to use? How does it behave if '%40' is replaced by '@'?


I would be surprised if merely stripping the '@' from the address made it too short. What is the value of ENTRY_EMAIL_ADDRESS_MIN_LENGTH? Was it properly set in the database (configuration table)? If it's undefined or some absurd value, it could trip this test. If Wesley was saying that the tep_validate_email() function was returning false (not the length test), that would not be surprising, given that there is no '@' in the address. PLEASE CLARIFY.

Link to comment
Share on other sites



When I set the code:

echo $HTTP_GET_VARS['account'];

The page shows "myemailgmail.com".

So I know that the HTTP_GET_VARS is the issue here.



So when the HTTP_GET_VARS['account'] strips the %40 out fo the email address and then gets converted to string $email_address. This stripped email address is invalid so when it is passed to the validation step, it fails.

Link to comment
Share on other sites

As Chris told you, $HTTP_GET_VARS does no processing of any kind. It's simply an array to hold data. That means that either whoever loaded this array element had already stripped out the '@', or it was initially loaded correctly, and someone processed it in some way to strip the '@'. You'll have to look upstream until you find whether $HTTP_GET_VARS obtained a bad value, or was loaded with a good one that someone altered.


'GET' variables come in from the URL Query String (...&account=myemail%40gmail.com...), where many symbols such as '@' have already been converted to %nn format.

Link to comment
Share on other sites

Ok NOW I finally understand, I thought that HTTP_GET_VARS was a PHP function and apparently it was, but was depriciated in PHP4.1 as per their website.


4.1.0 Introduced $_GET that deprecated $HTTP_GET_VARS.


I started working my way down the code. First Include is the Application_top.php file.

That file calls on line 41: compatibility.php. In that file is the code

if (PHP_VERSION >= 4.1) {

So at that point HTTP_GET_VARS = PHP GET function. So OCS instead of changing all their older HTTP_GET_VARS, they just placed a new array with the same name and assigned it the GET.


Anyway, it is the _GET that is stripping my AT symbol.

I entered the code on my page:

echo $_GET["account"];

and there is no symbol or the HTML code %40.


So I have searched the PHP site for how to keep the AT symbol when the variable is extracted from the URL.

Link to comment
Share on other sites

No, $HTTP_GET_VARS has always been an array, not a function. It has been deprecated in favor of the shorter $_GET array. osC still uses the old form ($HTTP_GET_VARS), so it copies $_GET into that array. NO FUNCTIONS INVOLVED.


At some point you should see a link URL with your email address in it: ...&account=myemail%40gmail.com... If the @ has already been removed (...&account=myemailgmail.com...), whoever is generating the URL is falling down on the job. It should be merely changing @ to %40. Do you have any kind of SEO installed? Maybe it's "cleaning up" the email address generation when it shouldn't be.

Link to comment
Share on other sites

Did you find any answer to this problem? I'm having the same problem after upgrading to 2.3.2 in a test environment.

The password reset function just won't work. The link in the email contains %40 for "@" but the webpage receives the email adress as userdomain.com instead of user@@Domain.com


Really frustrated her. what could be wrong? i guess it has to be with the server settings because not everyone is getting this error.

Link to comment
Share on other sites

You might ask your host if they have "mod_security" enabled, and whether it's configured to strip out %nn characters. If so, have it disabled and see if things improve. Otherwise, I can't think of why %40 in a URL would vanish when the $_GET array sees it -- I don't think osC itself is doing anything in that area. If a "mailto" href is being used for sending email, it would be a problem for any code that tries to "sanitize" or "prepare the URL" by translating all punctuation in a URL to %nn codes, to do this for an email address. But then, you shouldn't see it appearing as a link anyway.


Is an email address being passed through the URL Query String (into $_GET)? Part of splitting it up into $_GET array elements is supposed to be changing %nn back into the real bytes. If you can see the URL with %40 in it, it doesn't sound like any SEO add-on is messing it up. If the %40 is vanishing by the time it gets put into $_GET, my first suspicion would be "mod_security", or something else at the server level.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...