Check for Email Confirm bug is back

The bug is back and i have some debug code in place to show you what is happening.

Sorry for starting a new thread but I was not sure you would still check the old one after I told you the bug was gone.

NOTE: All pages are the default pages that came in the zip file except I added some debug code to the bottom.


Question:

Where is the (check / code) for WA_Auth_RulePasses("Email Confirmed")?
I did a site wide search and could not find the code.

Also any other input you can give me on this bug would be appreciated.



Repro:

Go to protected_Page.php
After you are redirected to the login page, register as a new user.
Do NOT reply to the confirmation email.
click the login link on the thank you page you are redirected to after you register.
Log in to the site and you will be redirected to the profile page.



Bug:

At the bottom of the profile page you should see the following:

===============
Raw UserEmailVerified database table entry for this user: 0

Test of show region: WA_Auth_RulePasses("Email Confirmed"): [PASSED]

Congratulations, you can access the protected page.
===============

If you click on the protected page link you will see the following: Logged in: youremail@domain.com (email verified).




Expected Results:

You should see [FAILED] after the email confirmed check.
The congratulation message should not show.
The verify button should show.




NOTE: I added the following test code to the default profile page below the update button

* Test Code *
===============
<p>Raw UserEmailVerified database table entry for this user:&nbsp;<?php echo $row_WAATKusers['UserEmailVerified'];?></p>

<p>Test of show region: WA_Auth_RulePasses("Email Confirmed"):&nbsp;

<?php if(WA_Auth_RulePasses("Email Confirmed")){ // Begin Show Region ?>
[PASSED]
<?php } // End Show Region ?>

<?php if(!WA_Auth_RulePasses("Email Confirmed")){ // Begin Show Region ?>
[FAILED]
<?php } // End Show Region ?>

</p>
============================

OK,

I found the server behavior for the statement: WA_Auth_RulePasses("Email Confirmed")

The server behavior code is as follows:

Allow if <?php echo $_SESSION['UserEmailVerified']; ?> = 1
Allow if <?php echo $_SESSION['UserID']; ?> <> empty

So i added code to check the session values for both 'UserEmailVerified' and 'UserID' to the page.

When I run the page the session 'UserID' is 4 and the session 'UserEmailVerified' is 0 however the WA_Auth_RulePasses("Email Confirmed") check still returns success.

I'm confused... How can the check return true if the values show up on the same page as being false?



Question:
Is the server behavior check for two entries an && or an || operation?

Example of AND operation: ((confirm == 1) && (userid <> null)) == true;
Example of OR operation: ((confirm == 1) || (userid <> null)) == true;

If the check is an OR operation it would explain the bug.
An OR operation of the two decisions would return true as the userid decision will return true even if the verified value is 0.


Question:
Why does the email confirmed server behavior include code to check the userid?






* Test Code *
===============
<p>Raw UserEmailVerified database table entry for this user:&nbsp;<?php echo $row_WAATKusers['UserEmailVerified'];?></p>
<p>SESSION UserEmailVerified:&nbsp;<?php echo $_SESSION['UserEmailVerified']; ?></p>
<p>SESSION UserID:&nbsp;<?php echo $_SESSION['UserID']; ?></p>

<p>Test of show region: WA_Auth_RulePasses("Email Confirmed"):&nbsp;
<?php if(WA_Auth_RulePasses("Email Confirmed")){ // Begin Show Region ?>
[PASSED]
<?php } // End Show Region ?>
<?php if(!WA_Auth_RulePasses("Email Confirmed")){ // Begin Show Region ?>
[FAILED]
<?php } // End Show Region ?>
</p>
==================================

OK,

I removed the check for the session UserID from the email verified server behavior and now everything works fine.

I looked in the HelperGroupsRulesPHP.php shipped in the original zip file I downloaded from your site and found the comparison rules for 'Email Confirmed'.

The rules are as follows:

...
case "Email Confirmed":
$comparisons[0] = array(TRUE, "".((isset($_SESSION['UserEmailVerified']))?$_SESSION['UserEmailVerified']:"") ."", 1, "1");
$comparisons[1] = array(TRUE, "".((isset($_SESSION['UserID']))?$_SESSION['UserID']:"") ."", 2, "");
break;
...

So you ship the product with the two checks.

This begs the following question: How did this ever work if the comparison check is an OR operation?



I'm looking at the code in Security Assist Helper_PHP.php now and trying to figure out how it works. I'm an old C++ guy though and I have never worked with PHP before so the going is slow. :)


I am worried though...

If you include the check for 'UserID' along with the check for 'UserEmailVerified' in the original source code there must be a reason. Also, why would the check work for a while then stop working?

Like I said... I'm confused.

I finished looking at the code for WA_Auth_RulePasses($ruleName) in Security Assist.

The function WA_Auth_RulePasses($ruleName) returns WA_Auth_RuleObject_EvaluateRules($ruleName).

WA_Auth_RuleObject_EvaluateRules($ruleName) goes through and checks each statement for a true result and returns true if either of those two statements evaluates to true.

This is an OR operation and I don't see how it could ever work.

Is this a bug in the code or am I getting it wrong somehow?

I found your bug: SOMETHING IS OVERWRITING THE FUNCTION WA_Auth_RuleObject_EvaluateRules.

Note, I have installed ALL of the WebAssist Extensions one at a time over the last month since I signed up for the WebAssist Extension Library program.

The function WA_Auth_RuleObject_EvaluateRules was somehow overwritten by another version of the same function and other functions in the file may have also changed!

I don't know when it happens but somehow this function is being overwritten in the SecurityAssist code on the site. This would definitly cause the symptoms I have experienced and seems to be the reason the check is failing now and didn't after I originally installed.

*** I believe one of the WebAssist extensions I have installed is overwriting the file ***


****************************************
Original version that shipped in the zip file.

File: Helper_PHP.php
Function: WA_Auth_RuleObject_EvaluateRules
Line 193

if((!$comparison[0] && $compareSucceeds)|| ($comparison[0] && !$compareSucceeds))
{
$rulePasses = FALSE;
break;
}
else if ($compareSucceeds)
{
$rulePasses = TRUE;
break;
}
**************************************************


**************************************************
The function in the version I now have on the site reads as follows:

File: Helper_PHP.php
Function: WA_Auth_RuleObject_EvaluateRules
Line 192

if(!$comparison[0] && $compareSucceeds)
{
$rulePasses = FALSE;
break;
}
else if ($comparison[0] && $compareSucceeds)
{
$rulePasses = TRUE;
break;
}
else if(!$comparison[0] && !$compareSucceeds)
{
$rulePasses = TRUE;
}
else if($comparison[0] && !$compareSucceeds)
{
$rulePasses = FALSE;
}
****************************************************

OK, this is how I repro the bug.

Install ALL of the WebAssist extensions that come with the WebAssist Extension Library program.

Create a new site and follow all the instructions for installing the User Registration Solution Pack. Install the db and all the files and edit your globals and connection files so the site operates as intended and is all new with no other edits.

You will notice that the user email validation server behavior works as intended and the Helper_PHP.php file in the SecurityAssist folder of your site is the same as the one that came in the zip file.

Create a new php template with an editable region for content and save it as a template. Do NOT apply the template to anything. There is no need to apply it to see the bug.

Now create a div in the body of the template above your editable region. I created the following code.

<div id="divRegMenu">
<table width="955" border="0" cellpadding="0" cellspacing="0">
<tr>
<td align="right">This will be the registration menu links.</td>
</tr>
</table>
</div>

Save all.

Select the code and go to your server behaviors panel.

Add the "SecurityAssist => Show Region" behavior and set the rule to "Logged In to Users".

Save all.

That's it. Check the Helper_PHP.php page and you will see that it has been changed to the new one that does not work.

My guess is that either the Security Assist extension has a bug in it's code where the helper page is overwritten with the wrong code, or the User Registration Solution Pack is being shipped with the wrong code and the rules file should not have the check for both the user id and the email verification.

Using features of the SecurityAssist extension cause the bug in the User Registration Solution Pack. This prevents me from using that extension if I want the User Registration Solution Pack to work correctly on my site. I want to continue using the SecurityAssist extension on the site after installing the User Registration Solution Pack so I need a fix for this.

I have SecurityAssist version "1.1.8" installed.

Please get back to me as soon as you can as my site cannot go live until I can get a fix for this issue one way or the other.

Thank you for putting in so much effort to get this worked out. I have checked the helper files myself and can see that they differ. What seems odd to me is that the helper file that comes from Security Assist should be the updated version.

To help get to the bottom of this I have opened a ticket for you. To check the status of the ticket or update it please visit your support history:

supporthistory.php

To summarize:
The version of the Security Assist > Helper_PHP.php file that comes in the User Registration Solution Pack and the version of this file that comes from Security Assist 1.1.8 differ. This causes the check for verified email to falsely show that the user has verified their email when this is not the case if using the version of this file that is generated by Security Assist.

The workaround:
make sure to use the version of this file that is included with the User Registration Solution Pack.

No problem, I'm an old software engineer and I just can't let a bug go unsolved. :)

Thanks for looking into it for me.

Yes, if a change is made using Security Assist after the User Registration Pack has been installed, files in the WA_SecurityAssist folder of the site are overwritten with versions that cause the User Registration Pack email validation to fail.

There may be more than one file that changes but the file that causes email validation to fail is "Helper_PHP.php", and the specific function is "WA_Auth_RuleObject_EvaluateRules".

The symptom is that an OR operation is performed instead of an AND operation when testing for the valid 'UserID' and 'UserEmailVerified' session variables within the WA_Auth_RulePasses("Email Confirmed") server behavior.



Thank you, i look forward to hearing back on the resolution.

Just thought I would let you know...

I talked with a dev this morning. (didn't get his name) Nice guy and he was very good at his job. Anyway, the bug is in the User Registration Pack in both the rule for email verification and also in the helper file. He says they will have an update out in a while.

Here is the fix...

1) Change the "Email Confirmed" rule with SecurityAssist to the following: "Restrict If (Session 'UserEmailVerified') <> 1"

2) Remove the UserID check.

3) The helper file will be updated to the correct one by SecurityAssist so there is no reason to change it.


The way the logic works is that the rule will return on the FIRST true answer. So if you have multiple checks in the rule, the first one to evaluate to true wins.

Example: In this case the "Email Confirmed" rule shipped with the User Registration Pack has two checks...

Allow if (Session 'UserEmailVerified') = 1
Allow if (Session 'UserID') <> null

If the user has logged in but NOT verified via email yet then the first check fails, the logic moves to the second check, and the second check succeeds returning true.

That is broken.

The correct logic is...

Restrict If (Session 'UserEmailVerified') <> 1

Since the session will not be there at all if the user has not logged in, there is no reason for the UserID check.
And since the page will be restricted if the 'UserEmailVerified' value is not equal to 1, the check returns false and the user is restricted from the page.


NOTE: I have the change made on my system but users of this package should be aware of the issue so they can make changes in their product.



- Mikel