This topic has 38 replies, 2 voices, and was last updated 10 years by 
-
-
I’m having an issue where a bad password entered into the login modal causes the login process to hang on “Sending info, please wait…”
Rather than displaying the proper error message.
Console shows a 403 error (forbidden) on admin-ajax.php, but obviously none of my users will see this.
Logging in through /wp-admin/ or /wp-login.php handles bad passwords just fine. This only occurs with the login modal, presumably because it uses ajax and the other login methods do not (?)
Could someone tell me if this is even a theme issue? The other methods of logging in with the twentyfourteen theme, etc, don’t use Ajax so it’s difficult to tell.
Update to this issue:
I have two issues with logging in via AJAX sweetdate modal:
1) When attempting to login to the website using a domain alias (e.g. dev.meetmindful.com which is an alias for mmdev.wpengine.com) I get the following console error even when the password is correct:
XMLHttpRequest cannot load http://mmdev.wpengine.com/wp-admin/admin-ajax.php. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://dev.meetmindful.com’ is therefore not allowed access.
…however the modal itself does not communicate any issue whatsoever. It just sits there with a “sending info..” message. This is a critical issue on our site with regard to user experience.
2) When attempting to login to the website at the original domain name (e.g. mmdev.wpengine.com) I get the following error when the password is incorrect:
POST http://mmdev.wpengine.com/wp-admin/admin-ajax.php 403 (Forbidden)
…but again the modal only shows “Sending info” and the user experience is entirely broken.
When I change the site URL to the aliased domain, e.g. “dev.domain.com” I can log-in via AJAX as expected, but then the issue reverses.. and I cannot login via AJAX at installname.wpengine.com
For now this is fine so you can close this issue,
Sorry, changed back to not resolved because I still have the second issue described above.
When entering the WRONG password I get :
Failed to load resource: the server responded with a status of 403 (Forbidden) on admin-ajax.php (in console)
…but the login modal just spins the “Sending info” message and the user has no idea what’s happening.
Hi, Please update to latest version and see how it goes. Seems to be a problem since wp-admin/admin-ajax.php can’t be accessed and that file is required for AJAX requests not just by the login script
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.I’m using 3.9.1 and BP 2.0.1 and SweetDate 2.6
Is this a compatibility issue with the theme? I realize SD2.6 lists compatibility only up to BP 1.9
I need to find a temporary fix even if it means hacking core for the time being, as we have some important user testing sessions coming up in 3 days. Right now the problem is limited to the handling of bad passwords. I just need to fix the indicator on the login modal so that it once again notifies the user that they are not progressing because of a bad password.
2.6.1 is the latest. Re-download the theme. Like I said above is a problem with your configuration since wp-admin/admin-ajax.php needs to be accessible and it is not
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.Ok I created a fresh install on WPengine with BP 2.0.1 on WP 3.9.1, and SweetDate 2.6.1
Without even getting into domain aliases, I tested on the default Wpengine domains, and found that through the login modal a BAD password results in this (console):
POST http://mmstock.wpengine.com/wp-admin/admin-ajax.php 403 (Forbidden)
(and then a second later)
POST http://mmstock.wpengine.com/wp-login.php net::ERR_EMPTY_RESPONSE65.103.116.25 mmstock.wpengine.com – [15/May/2014:21:15:16 +0000] “GET /wp-admin/admin-ajax.php?action=wp-compression-test&test=1&1400188514561 HTTP/1.1” 200 574 “http://mmstock.wpengine.com/wp-admin/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36”
65.103.116.25 mmstock.wpengine.com – [15/May/2014:21:15:16 +0000] “GET /wp-admin/admin-ajax.php?action=wp-compression-test&test=no&1400188514907 HTTP/1.1” 200 21 “http://mmstock.wpengine.com/wp-admin/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36”
65.103.116.25 mmstock.wpengine.com – [15/May/2014:21:15:17 +0000] “GET /wp-admin/admin-ajax.php?action=dashboard-widgets&widget=dashboard_primary&pagenow=dashboard HTTP/1.1” 499 0 “http://mmstock.wpengine.com/wp-admin/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36”This has to be a WPengine thing because I set up the same stack on my personal linode server and bad passwords are handled just fine.
If theres anything you guys can point out that may help me in dealing with WPengine support staff that would be GREAT!
Since the admin-ajax is forbidden it could the the cause of a plugin or misconfiguration on site url or try to talk at wpengine maybe it is something related to their security
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.So I tested this with only buddypress and sweetdate — no other plugins, and the issue remains. So it’s definitely a configuration issue.
I’ll try experimenting with site URLs and wp HOME.
Any clues here?
Request headers
COPY CODEPOST /wp-admin/admin-ajax.php HTTP/1.1 Host: mmstock.wpengine.com Connection: keep-alive Content-Length: 60 Cache-Control: no-cache Pragma: no-cache Origin: http://mmstock.wpengine.com X-Requested-With: XMLHttpRequest Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36 Referer: http://mmstock.wpengine.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8,es;q=0.6 Cookie: optimizelyEndUserId=oeu1399400978451r0.49796974984928966; _jsuid=2814151028; hsfirstvisit=http%3A%2F%2Fwpengine.com%2F2014%2F02%2F25%2Fwp-engine-introduces-copy-site%2F|https%3A%2F%2Fwww.google.com%2F|1399530671818; __utma=67904087.465359914.1399530670.1399530670.1399530670.1; __utmc=67904087; __utmz=67904087.1399530670.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); optimizelySegments=%7B%22852260298%22%3A%22false%22%2C%22858250216%22%3A%22search%22%2C%22858450478%22%3A%22gc%22%7D; optimizelyBuckets=%7B%7D; _referrer_og=https%3A%2F%2Fwww.google.com%2F; _ga=GA1.2.465359914.1399530670; __hstc=51647990.d59f5ec2ffcf79f21c6a06ff9caf2b77.1399530671820.1399996188709.1400187085641.4; __hssrc=1; hubspotutk=d59f5ec2ffcf79f21c6a06ff9caf2b77; wp-settings-time-2=1400190771; wordpress_test_cookie=WP+Cookie+checkresponse headers
COPY CODEHTTP/1.1 403 Forbidden Server: WP Engine/6.0.2 Date: Fri, 16 May 2014 18:00:01 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 118 Connection: keep-alive Keep-Alive: timeout=20 Access-Control-Allow-Origin: http://mmstock.wpengine.com Access-Control-Allow-Credentials: true X-Robots-Tag: noindex X-Content-Type-Options: nosniff Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Encoding: gzip^nvm the above
ajaxurl is set properly and admin-ajax can be accessed when doing other things like retrieving a password.
It is only when a bad password is entered that this occurs.
Actually on my vanilla install of sweetdate/bp ajaxurl is not being defined on the home page at all? So password retrieval doesn’t work either
it has to be defined on the page before loading app.js file, otherwise the request wouldn’t know to go to the ajax url
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.admin-ajax is defined on my DEV install and STAGING install, and still suffers from the issue described here, where admin ajax returns 403 if the password is incorrect.
FYI the demo site shows 500 internal server error on admin-ajax.php when you load the home page.
QUESTION: Is there any to modify is_wp_error to include a case for 403 on admin-ajax?
COPY CODEadd_action( 'wp_ajax_nopriv_kleoajaxlogin', 'kleo_ajax_login' ); if (!function_exists('kleo_ajax_login')): function kleo_ajax_login() { // Check the nonce, if it fails the function will break check_ajax_referer( 'kleo-ajax-login-nonce', 'security' ); // Nonce is checked, get the POST data and sign in user $info = array(); $info['user_login'] = $_POST['log']; $info['user_password'] = $_POST['pwd']; $info['remember'] = true; $info = apply_filters('kleo_ajaxlogin_atts', $info); $user_signon = wp_signon( $info, false ); if ( is_wp_error($user_signon) ){ echo json_encode(array('loggedin'=>false, 'message'=> '<i class="icon-warning-sign"></i> ' . __('Wrong username or password. Please try again.', 'kleo_framework'))); } else { $redirecturl = apply_filters( 'login_redirect', '', '', $user_signon ); echo json_encode(array('loggedin'=>true, 'redirecturl' => $redirecturl, 'message'=> '<i class="icon-ok-sign"></i> ' . __('Login successful, redirecting...','kleo_framework'))); } die(); } endif; add_action( 'wp_ajax_kleoajaxlogin', 'kleo_ajax_login_priv' ); if (!function_exists('kleo_ajax_login_priv')): function kleo_ajax_login_priv() { $link = "javascript:window.location.reload();return false;"; echo json_encode(array('loggedin'=>false, 'message'=> '<i class="icon-warning-sign"></i> ' . sprintf(__('You are already logged in. Please <a href="#" onclick="%s">refresh</a> page','kleo_framework'),$link))); die(); } endif;I meant to say “ajaxurl” is defined properly on dev/staging, where the 403 issue STILL occurs.
For some reason on my bare-bones ‘stock’ install with just BP and SweetDate and no customizations, ajaxurl is not being defined before being called. BUT proper login/password combinations work. Again, only the bad combinations trip up.
Wordpress Engine says this about the issue:
The 403 comes from our plugin. You can find the code for that here: /wp-content/mu-plugins/wpengine-common/plugin.php
function wpe_login_failed_403() {
status_header( 403 );
}
add_action( ‘wp_login_failed’, ‘wpe_login_failed_403’ );
The form action for the modal box has wp-login.php hardcoded, and bypasses our login protection which is part of the issue. Here is what the form action URL should look like: http://cl.ly/image/1S1e0l143c2R – And here is the code I suggest as an alternative:<?php echo esc_url( site_url( ‘wp-login.php’, ‘login_post’ ) ); ?>
The modal box currently uses this code to generate the form action:<?php echo wp_login_url(apply_filters(‘kleo_modal_login_redirect’, ”) ); ?>
The WordPress Codex also recommends site_url over wp_login_url.I tried the suggested fix and nothing changes. I see the form action now has the extra parameter but this doesn’t help… admin-ajax stil 403, it seems the wp_signon is never taking place.
Wordpress does no recommend that functions over wp_login_url. The recommendation is for the redirect parameter.
Also that form action has nothing to do with the AJAX login and wp-admin/admin-ajax.php
Like I said wp-admin/admin-ajax.php should be accessible and this is not just a requirement of our AJAX login but plenty other WordPress functions.The function that takes care of the login is the one you pasted above, maybe it helps in the debug process the guys at wpengine
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.wp-admin/admin-ajax.php is accessible in all other functions of the website, except when handling a bad password.
The 403 header is applied by the wpengine plugin
COPY CODEfunction wpe_login_failed_403() { status_header( 403 ); } add_action( ‘wp_login_failed’, ‘wpe_login_failed_403′ );In my case.. it may not actually be an appropriate header?
Since the modal hangs on “Sending info..” then it seems the wp_signon is never actually taking place? Because if it was, then the check immediately afterward should either be showing me the “wrong password” message OR redirecting me elsewhere. Right? But it’s doing nothing.
COPY CODE$user_signon = wp_signon( $info, false ); if ( is_wp_error($user_signon) ){ echo json_encode(array('loggedin'=>false, 'message'=> '<i class="icon-warning-sign"></i> ' . __('Wrong username or password. Please try again.', 'kleo_framework'))); } else { $redirecturl = apply_filters( 'login_redirect', '', '', $user_signon ); echo json_encode(array('loggedin'=>true, 'redirecturl' => $redirecturl, 'message'=> '<i class="icon-ok-sign"></i> ' . __('Login successful, redirecting...','kleo_framework'))); }When tested http://mmstock.wpengine.com/ and putting a wrong user/pass in the popup I get redirected to wp-login.php which is the fallback for unsuccessful AJAX requests. So that behavior should be fine
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.Yes I would be OK with that as a temporary solution, but now need to figure out why that isn’t occurring in our customized version of the theme, elsewhere, where the modal just hangs on ‘Sending info…’
DO you have a live site to see that hanging? since it can be debugged from the ajax request
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.also see post 18183? not sure if that helps..
are you ‘chrismanners’ ? if not i’m incredibly shocked that someone seemingly random has already signed up. Haha
No it wasn’t me 🙂
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.Update to 2.6.1 since the fallback was added in the latest version
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.Hi Abe, I believe I updated to 2.6.1 some time ago, at least with the main /sweetdate/ theme folder anyway. I didn’t grab and over-write the child theme… I’m still fuzzy on best practice for rolling in sweetdate updates, and what to do with the child theme folder.
Anyway. WPEngine will be making some changes to their core (‘required’) plugin as a result of my ticket. They pushed a fix to a bare-bones/vanilla install I had setup (‘mmstock.wpengine.com’) and their fix solved this issue.
The child theme should not get updated since it has your customizations. Main theme is best not to apply changes to it for easier updates and make the required changes in the child theme. I looked at sweetdate main theme style.css version on that server and was 2.6. Try updating just the main theme functions.php since there is the updated code for the fallback and the assets/scripts/app.js
That is great
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.Going to mark this resolved and post the code that WPEngine is using to fix sites with this issue:
COPY CODE<?php /** * Plugin Name: Fix AJAX 403 * Plugin URI: https://gist.github.com/JPry/c8ad046c49f3f4a54377 * Description: Prevent bad AJAX login requests from generating a 403 code * Version: 1.0 * Author: Jeremy Pry * Author URI: http://jeremypry.com/ * License: GPL2 */ // Prevent direct access to this file if ( ! defined( 'ABSPATH' ) ) { die( "You can't do anything by accessing this file directly." ); } add_action( 'muplugins_loaded', 'jpry_adjust_wpe_hooks' ); function jpry_adjust_wpe_hooks() { remove_action( 'wp_login_failed', 'wpe_login_failed_403' ); add_action( 'wp_login_failed', 'jpry_login_failed_403' ); } function jpry_login_failed_403() { // Don't 403 for Ajax requests if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) { return; } status_header( 403 ); }Great. Thank you
Hi there!!! Help others from the community and mark any reply as solution if it solved your question. Mark as a solution---
@ SeventhQueen we do our best to have super happy customers. Thanks for being our customer.
The topic ‘Login modal not exposing issues with passwords/admin ajax permissions’ is closed to new replies.
