-
-
Notifications
You must be signed in to change notification settings - Fork 113
Retry segment causes application to fail #189
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Ok we still had the issue it just occurred later. |
My concern with the code is that the close looks to dereference not actually end the connection especially if an error were to occur during the close. If you need further information I can provide you whatever you need. |
Thanks for reporting this – at the moment I'm not quite sure which retry functionality you are referring to, because the error message you've posted relates to local server mode. Do you mean when an authentication request fails, for example due to being rejected by the user? It would be useful if you could point to exactly where you think the issue is being caused and what you've changed. Also, could you clarify whether you are using the issue-183 branch, which separates out the token error from other connection issues? |
We are using thead safe branch because we were getting config corruption when we got this error and had to redeploy. The retry I'm talking about is the retry in the |
Thanks – it's worth trying the concurrent branch that you are using in conjunction with the issue-183 branch because that separates out the token error in a different way. Could you try the issue-189 branch, which merges the two? (I intend to merge both of these into the main project anyway once the original reporters are able to test) |
We did try 183. Got the following error. |
The token works again after restart. |
Have you set |
Yes there are multiple clients. I'll try the delete_account_token_on_password_error to false. Even if this was the case we should get a good one the next time the correct password is sent. But by this time the entire connection is gone and we get the above port error. |
The port error is explained in the documentation - local server mode is an extra feature to support situations where interactive authentication is not possible. Improvements are welcome if you spot another way to handle this, but it's a bonus capability rather than the core focus for the proxy. It's fine to use multiple clients at the same time, but they do all need to use the correct password. |
Did you resolve this? I'll close the issue if so. |
No we're still having issues. We're still trying to identify if this could be email password related. We haven't found 1 yet. |
Were you able to make any progress here? |
I intend to close this issue in the next few days under the assumption that it has been resolved, but just let me know if that's not the case. |
So I think the issue is still there in the retry code. You did mention that this was "enhancement" feature but it looks like if you're running headless and an auth fails the application will stop working. So at least I would recommend something that bypasses this route. |
Thanks for following up. I may be completely missing something here, but I don't see how the retry can cause the proxy to fail. The proxy closes the local server after finishing using it (whether successful or failed), and even if this is for whatever reason not happening properly, you can reconnect the client (perhaps after a short wait for the socket to be cleared up). How can I replicate this to look into it? And what am I missing that means your setup doesn't close the local authentication server? |
Hello, I tried setting Any other approaches? |
Interesting that you say it only happens for SMTP. Are you 100% sure that your client is using the same password for SMTP and IMAP? I will need to see a proxy log (in
To be clear, you change the value of |
Oh, no, i changed the code. I try to edit it in the config. Is it correct to just add So, i tried to log everything. Firstly, i authorize while fetching mails via imap:
After successfully authorizing, fetching works. I can send Email (also via your proxy) from different accounts such as admin@, mark.something@ and the problematic mail account fetches them. But then i try to send an email via smtp:
I can either authorize again, then it will mostly send the mail, but for another email it will need another authorization. If I skip it, he can still receive emails. |
Thanks – this is really useful. Two things to follow up on:
I need you to check that, firstly, the same values are printed for both IMAP and SMTP (to make sure you don't have, say, an old SMTP password cached in your client). Based on your log above, the relevant values in the debug log after this change should be something like:
It is critical that the output after the connection details and IMAP/SMTP commands is character-for-character identical in both cases (the If the values are identical, and you can provide me with the actual values you see here (perhaps after changing your password in your client to something temporary) then all the better. |
You are right!! There are two different passwords! |
Thanks for following up and confirming this – I'm glad this turned out to be on the client side rather than an issue with the proxy. I'll merge the minor changes from this branch and add documentation about the fact that many clients (mostly for historical reasons) support different passwords for POP/IMAP and SMTP, and that it is important to be sure that these are identical. In terms of tips for password management, it's worth reiterating that the password used by your client with the proxy does not need to be the same as your actual account password, so you can perhaps manage this using a different approach. Conversely, if you want to use the same password for both the proxy and your actual account, this is also okay. Whatever works best for you. |
Hey not a python developer but am using your email proxy program. We ran into an issue where the invalid token exception would retry and fail. Needed to restart to recover. I removed the retry functionality contained in and we no longer seem to have the issue.
The following is the error we would receive after a retry attempt.
Email OAuth 2.0 Proxy Local server auth mode: please authorise a request for account rtoc@moblize.com
2023-08-22 15:52:43: Local server auth mode (localhost:6767): unable to start local server. Please check that
redirect_uri
for rtoc@moblize.com is unique across accounts, specifies a port number, and is not already in use. See the documentation in the proxy's sample configuration file. OSError(98, 'Address already in use')We are running in non-qui mode.
The text was updated successfully, but these errors were encountered: