-
-
Notifications
You must be signed in to change notification settings - Fork 879
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting RecursionError when Jira servers return 401 #681
Comments
I am seeing the same issue communicating with a JIRA Server instance (instead of Jira Cloud). But it only goes into this for me when I call
if instead I call
The 401 is flagged as Got recoverable error and it tries again (which fails as it is not logged in) |
When I stopped using basic auth and switched to using oAuth, all these issues went away. It was a pain to setup authentication the first time, but it helped 100%. |
I figured out my 401 error - so no longer imacted by this. But it is still a bug ;) |
Can you elaborate on your solution to the 401 issue more @ssorgl |
@rsvancara - that was easy: provide the correct credentials! :) Once I realized that it was getting a valid 401, I re-examined my credentials and realized I had not provided the correct string for the user! |
Getting the same error when providing incorrect credentials in a similar way as ssorgl did. Right now one has to handle a RecursionError when providing incorrect credentials. Could this be changed to return a JIRAError with the appropriate 401 status code? |
Please note that cookie-based authentication is now being removed from Jira API. So instead of fixing this bug this feature could be removed altogether (if backwards compatibility is not a concern). |
I will have to try it out to verify that this is not going to be an issue using and API Token (one of the recommended replacement methods). If I read correctly, the client call will go from: Has someone tested that not providing the correct credentials (which would still result in the same 401 error from the server I believe) does not just end up in the same recursion error? I suspect it would (same method call, and I believe the same error response from server), but have not had time to test yet. |
Actually I think that basic auth should be used instead.
to:
works fine. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You way want to consider using the Sponsor button in order to persuade someone to address it. |
I've noted this issue in the latest version. It is causing an issue because the plugin attempts to login hundreds of times until the account is locked. |
Thanks! |
recursion restriction needs to be added to handle_401, because simply resending w/o reservation is bad. I would suggest we get a sha of the request and cache it with a count, clear the retry_cache before sending new requests and all should be good init
verification/usage:
|
The fix could be to passing 'self._session.max_retries' to JIRA._create_cookie_auth() function that could be used by JiraCookieAuth(), so JiraCookieAuth.handle_401() doesn't happen forever like it does now until we see 'RecursionError: maximum recursion depth exceeded in comparison', which is same concept as @suederat is suggesting |
Getting
RecursionError: maximum recursion depth exceeded in comparison
when getting 401 error codes from Jira using JiraCookieAuth. This looks due to the handle_401 register_hook being passed to the request module in client.py:221. The handle looks like it simply retries the request, but has no mechanism in place to prevent it from retying indefinitely, thus the recursion error.Commenting out the line
request.register_hook('response', self.handle_401)
in theJiraAuthCookie
class still shows 3 retires to occuring with a pause between each retry. It also stops the RecursionError error from happening, and I assume thrashes the Jira servers much less.Python 3.5.3
Jira Client: jira-2.0.1.dev17
Communicating with Jira Cloud
Stack Trace
The text was updated successfully, but these errors were encountered: