[Regression] In 2.4 "Credentials Wrong" state does not retrigger the password-asking form #5989
Assignees
Labels
Milestone
Comments
|
@ogoffart I've debugged this using mitmproxy, and what seems to be happening is this: When the password is rejected, we do call Do you have any ideas about why the request would not be performed? (there's no entry in mitmproxy for it) |
|
@ckamm: I have no idea, if askFromUser is called, then normally the GET should be done. Some debuging might be in order. |
|
Yeah, I'll look at it more deeply today. It's confusing that the GET request doesn't even go out. Also, I think this might deserve code sharing with DetermineAuthType - currently it doesn't deal with redirections properly. |
|
Debugging has yielded the following (thanks to @guruz, @jturcotte, @ogoffart for suggestions):
Possibly a QNAM bug in Qt 5.7.1? Backtrace for @guruz |
|
@guruz FWIW: I get the same incorrect behavior if I don't |
|
@SamuAlfageme Is this a self-compiled client with which Qt version? |
|
@guruz nope, it's a month-old nightly:
|
|
Todo here: Apply workaround. But since this is also a somewhat scary issue: Check whether it's fixed in newer Qt versions. Try to make a small test case. |
ckamm
added a commit
that referenced
this issue
Sep 7, 2017
When the GET request from askFromUser is scheduled on the QNAM inside the slot that handles the QNetworkReply::finished signal, it seems to not get processed at all. This workaround moves the sending of the new GET to the event loop, sidestepping the problem.
ckamm
added a commit
that referenced
this issue
Sep 7, 2017
When the GET request from askFromUser is scheduled on the QNAM inside the slot that handles the QNetworkReply::finished signal, it seems to not get processed at all. This workaround moves the sending of the new GET to the event loop, sidestepping the problem.
|
Solved by workaround. I've also tested with Qt 5.9.1 and the same bug manifests itself. This might bite us in other codepaths, so I'll spend some time trying to create a test case we can use to report and fix this problem upstream. |
|
PR #6002 |
|
This test case doesn't reproduce the problem unfortunately: |
|
@ckamm I'm running into the exact same behavior w/ today's nightly 😕 Trying to sign-back-in adds a temporary (just appears and disappears) entry to the keychain. Stays "Conecting..." and further login attempts preserve the wrong password on the credentials dialog. |
|
This was pretty hard to track down. Can you reproduce and get a mitmproxy log? I'm wondering whether the workaround doesn't cover all cases, or whether you run into a different situation. |
|
@ckamm sure, repro steps w/ 2.4.0alpha1 (build 8391) [macOS]:
Actual Result (click to see video):
|
|
@SamuAlfageme Thanks, investigating. |
|
For people testing this: I just was significantly confused for a bit because there's a bug in mitmproxy 0.18.2's sticky auth that makes it always on: mitmproxy/mitmproxy#1850. Use |
|
I can reproduce the problem now. The workaround I added seems insufficient for not having that DetermineAuthType job's request eaten by QNAM. I'll attempt further debugging. |
|
The bug is due to a badly timed |
|
@SamuAlfageme Try again now. |
|
@ckamm neat' 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected behavior
After receiving the 401: Unauthorized from the server (
<s:message>No public access to this resource., Username or password was incorrect, Username or password was incorrect</s:message>) client 2.3.3 displays again the password dialog.Actual behavior
The status on the account tab stays
Connecting to <server> as <username>...until it times out and switches toSigned out...:Steps to reproduce
The text was updated successfully, but these errors were encountered: