Password_Reset.php $HTTP_GET_VARS removed @ symbol

[wjscomputerworks]

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?

[Chris H]

It seems more likely that

 

strlen('youremailaddress')

 

is less than

 

ENTRY_EMAIL_ADDRESS_MIN_LENGTH

 

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.

[MrPhil]

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.

[wjscomputerworks]

MrPhil,

 

When I set the code:

echo $HTTP_GET_VARS['account'];
exit;

The page shows "myemailgmail.com".

So I know that the HTTP_GET_VARS is the issue here.

The ENTRY_EMAIL_ADDRESS_MIN_LENGTH is set to 6.

 

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.

[MrPhil]

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.

[wjscomputerworks]

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) {
$HTTP_GET_VARS =& $_GET;

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.

[MrPhil]

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.

[arovik]

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.

[MrPhil]

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.