Front-end Login form – 403 error

[Tim]

Hello,

I’m trying to come up with a way to fix the 403 forbidden errors that occur with a front-end login form. It seems that the problem is caused by having HTML tags in $_GET[‘wp-error’].

I’ve tried filtering the login_errors, but it seems like that only works for a standard login page.

Is there a way to allow some HTML tags on a front-end login page using custom BPS rules? Or another method that would be better?

Thanks,

Tim

[AITpro Admin]

Is the frontend login form a plugin?  If so, post the name of the plugin.  Is the frontend login code, custom code that you created yourself?  If so, post your custom code.  Post the 403 error from your BPS Security Log so I can see what is being blocked.  “I’ve tried filtering the login_errors” – post the code you used to filter login_errors.  Post an example of what an HTML tag is or an example of your code.  You can use sprintf to output html characters in messages.

return new WP_Error('invalid_username', sprintf(__('<strong>ERROR</strong>: Invalid username. <a href="%s">Lost your password?</a>'), wp_lostpassword_url()));

[Tim]

The error I receive says:

[domain] 403 Forbidden Error Page
If you arrived here due to a search or clicking on a link click your Browser’s back button to return to the previous page. Thank you.
IP Address: [IP]

The URL at this point is "/products-page/your-account/?login=failed&wp-error=%3Cstrong%3EERROR%3C%2Fstrong%3E%3A+Invalid+username.+%3Ca+href%3D%22http%3A%2F%2Fwww.ariesmfg.com%2Fwp-login.php%3Faction%3Dlostpassword%22%3ELost+your+password%3F%3C%2Fa%3E&pr-user-login=asdfsfsdf"

If I remove the encoded HTML tags from the URL but leave the rest, the 403 error does not display, and I see the login form again as expected.

The login form is in a theme file using wp_login_form() with default arguments. The site is running WP E-Commerce, so it is in the template file for the “My Account” page. Leaving out all of the WP E-Commerce code, it simply says:

	if ( is_user_logged_in() ) : 
		get_currentuserinfo();
		//etc
	else :
		wp_login_form();

To filter the login error, I tried this method:

function _wp_login_custom_failed( $error ) {
    return "error message test";
}
add_filter( 'login_errors', '_wp_login_custom_failed');

This changes the error message when using the admin form, but does not change the wp-error parameter in the front-end form, so it doesn’t fix the 403 problem.

I also tried returning a new WP_Error like you have above, but that produces a PHP error because the function expects a string at that point.

Lastly, I confirmed this is caused by the BPS rules by deactivating BPS.

Thanks,
Tim

[Tim]

An alternative solution just dawned on me: The wp_login_failed action. I can redirect to a URL at that point rather than modify the error message.

If you have another solution please share, but this works well enough in this case.

Tim

[AITpro Admin]

If I remove the encoded HTML tags from the URL but leave the rest, the 403 error does not display, and I see the login form again as expected.

What is being blocked are the url encoded angle brackets %3C and %3E or < and > and the double quotes %22 or ” since these are in top 4 most dangerous html code characters used in Query Strings. If you have the BPS plugin installed then you can allow these dangerous html code characters in Query Strings, but I highly recommend that you do not allow that on your website and instead use an alternative method for the outputted Query String that does not contain these dangerous code characters.

A general safe rule of thumb and best practices for Query Strings is to use the field-value pairs format: field1=value1&field2=value2&field3=value3...
Your processing code should contain any code that is considered unsafe in outputted html code in Query Strings. ie the Query String should trigger your processing code instead of processing directly in the Browser Query Strings.

Example:  /products-page/your-account/?login=failed&wp-error=error1&url=url_value&action=lostpassword&a=b&x=y&user-login=login_value.  Then in your processing code that processes the Query Strings you would have the corresponding field/value actions occur.

[Tim]

Thanks. I set it up now following that method: Redirecting with failure key/value pairs, and outputting the error message and HTML needed in the template rather than from the URL.

It seemed odd that the HTML is in the URL now. I am not sure if WP E-Commerce or another plugin is causing that, or if it is native WP behavior when using wp_login_form().

[AITpro Admin]

WP uses standard field value pairs in all Query Strings, but does allow you to output HTML in error messages in-page.  The in-page error messages would be outputted in the Source Code of the login page and not in the Browser address bar.  An example would be if someone entered an incorrect password and you are using custom error messaging code to ouput your custom error message somewhere in-page above the login form itself.

[Author]

Posts