Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#4989 closed defect (bug) (reported-upstream) and other sites say username and password are empty after successful login and math test

Reported by: wordgear's profile wordgear Owned by:
Milestone: Priority: normal
Component: Login & Authentication Keywords:


This has been consistent... if we log in with our username and password, then pass the math test, we'll be redirected to the login page with the error that the username and password are empty.

Change History (12)

#1 follow-up: @dd32
4 years ago

As far as I've been able to tell, this happens usually around 00:00-01:00 UTC when Jetpacks Brute Protection more often fails to return a 'safe' result for the current IP address.

I think having the user/pass be discarded in that math flow is expected, although it's definitely jarring bad user experience. Perhaps someone from Jetpack can confirm how the math protection is supposed to work, so we can figure out if it's a Math or issue..

#2 @wordgear
4 years ago

It's 02:31:14 UTC and it just happened to me when I tested in Incognito (I don't get the math question anymore in normal session). This happens every time I get the math question.

Maybe you should try troubleshooting and debugging in Incognito mode.

We will be having multiple clients on our future site, maybe thousands, and if they want to use their username, they may become frustrated and may generate a lot of support calls.

#3 @dd32
4 years ago

My apologies, I didn't mean to infer that this only happens between 0-1am UTC, only that I've seen it more commonly happen to myself during those hours.

Testing using incognito shouldn't help as the test that's failing and triggering the Math block is purely based on the client IP address, it's also cached, so it should realistically only happen once per IP per few hours.

The only way I've been able to reproduce getting the Math block consistently has been to falsify the API response for the Jetpack Protect APIs (or sending the incorrect password enough times that the API deems my IP address unsafe).

#4 in reply to: ↑ 1 ; follow-up: @dd32
4 years ago

Replying to dd32:

I think having the user/pass be discarded in that math flow is expected, although it's definitely jarring bad user experience.

Looks like 'forgetting' the user/pass is the expected behaviour from the Math Fallback, as it contains no logic to remember/pass the attempted username through:
(The Math fallback is also only used if the Protect API is unavailable..)

That means the bug here really is that displays the incorrect message - it shouldn't mention empty user/pass, but rather just re-prompt for details I guess.

#5 in reply to: ↑ 4 @tellyworth
4 years ago

Replying to dd32:

There are several unresolved Jetpack issues that refer to similar issues. Here's a comment in detail, issue 2 seems to match our passthrough problem:

Seems like this should go upstream as (at least) two separate issues (the midnight thing, and passthrough)?

#6 @wordgear
4 years ago

@dd32 You said "this happens usually around 00:00-01:00 UTC", but it happens to me no matter what time it is as long as I have to fill out the math problem (from a username login).

I suggested testing in Incognito because you'll get the math problem, when it otherwise won't show in normal mode. This means you close any Incognito windows then log in with your username, then get the math problem and pass it to see the empty username error (during which you can debug the code and catch what's actually happening in your testing). I only suggested this as a way to guarantee getting the math problem.

Showing the wrong error message doesn't seem to be the problem; there's still the underlying logical problem where it doesn't log you in after you pass the math problem when logging in with your accurate username and password.

Maybe it needs to be clearly stated here that when you log in with your accurate username and password (and the form says you can use your username) and then successfully pass the math question, that it should log you in, not send you back to the login form with any error at all.

I hope this logic is clear, and that you can test and troubleshoot and debug this issue properly. If you need help with it, I can try to do that myself to catch the problem. The code should all be in PHP and JavaScript as far as I can deduce (since the problem happens on any install of WordPress 5.x I've tried regardless of domain or locality), and the coders fixing it at the source should fix it for all WordPress installations with the fix.

Last edited 4 years ago by wordgear (previous) (diff)

#7 @dd32
4 years ago

  • Resolution set to reported-upstream
  • Status changed from new to closed

Reported the bad UX to Jetpack -

Reported an API weirdness that may not be an issue at all -

I haven't been able to reproduce the early-hours-UTC problems, I suspect this is more of a transient API issue with Protect, that the above issues may resolve well enough.

I'm closing this ticket as reported-upstream as Protect is a part of the Jetpack plugin and this isn't related to specifically, other than their bugs affecting us too (But we're not going to work around them specifically for

#8 @wordgear
4 years ago

The behavior is intentional by design to prevent some edge cases?

This makes no sense. Logging in with the math problem literally doesn't log you in, and gives an incorrect error message.

I've never seen a site do this, much less the developers say it's intentional. It's completely contradictory to its purpose - to log you in with the username and block bots with a math problem... not fail to log you in then tell you the username was not even entered.

#9 @dd32
4 years ago

@wordgear This isn't my "thing" and isn't something that I can "fix" here. The Jetpack plugin is a plugin by Automattic, not I don't have a say in how it works, and WordPress can't force it to work in a certain way.

Feel free to follow up on the above Github issue I've made for it if you feel strongly about it.

But yes, the Math problem is NOT a login, it's a block in the event the IP address you're logging in from is flagged as not-good by the Jetpack Protect system, and that should only happens if your IP address has lots of failed login attempts (Or possibly, bad traffic to other things and they're using another IP blocklist or some such, I don't know how the Jetpack API works).

#10 @wordgear
4 years ago

Obviously there's a bug in JetPack because the issue happens each and every time I get the math problem, including the first times I logged into the sites, which was just in the last few weeks.

However, in the bug you filed, you say "According to #2097 this may be intentional, but it's a bad user experience."... which is why I left my statement questioning it here.

Why JetPack would "block" me the first time and each subsequent time I log into or any other modern WordPress site (5.2.5+) even though I just logged into them within the last few weeks... I just think you're mistaken that it's intentional.

#11 @dd32
4 years ago

Why JetPack would "block" me the first time and each subsequent time I log into or any other modern WordPress site (5.2.5+) even though I just logged into them within the last few weeks... I just think you're mistaken that it's intentional.

Unfortunately I can't answer that for you. You'll need to contact the Jetpack Support team. From what I understand, if your IP address has many failed logins to WordPress sites, you'll have the experience you currently are. It may be that you're using a shared IP address (Some ISPs have proxy servers/etc which can affect that, even without customers knowing) in which case it could be another ISP customer causing your problems.

#12 @wordgear
4 years ago

I've been logging in with different computers at different locations, so I don't think it's a matter of logging in with the same IP too many times.

I'm just not convinced this is anything but a bug; that's all I'm trying to say.

I find it hard to imagine that this is functioning as intended.

Note: See TracTickets for help on using tickets.