path double up issue with redirect_uri #146
Description
Hi,
First thanks for this project. It's awesome.
Apologies if this sounds like I am re-opening an old issue.
I have an issue related to the redirect_uri and a sort of double up on the path component of the redirect_uri. I have worked around it by reverting a recent update to emailproxy.py and I am trying to understand why. My setup is debian and authing with Microsoft. My emaillproy.config looks like
[myuser@mydomain.com]
permission_url = https://login.microsoftonline.com/common/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/common/oauth2/v2.0/token
oauth2_scope = https://outlook.office365.com/IMAP.AccessAsUser.All offline_access
redirect_uri = https://myotherdomain.com/oauth-handler/MicrosoftOauth2Redirect
redirect_listen_address = http://0.0.0.0:8080
client_id = 1234
client_secret = 5678
I am running the proxy like so inside a container
python /email-oauth2-proxy/emailproxy.py --no-gui --local-server-auth --config-file /somepath/emailproxy.config
I have a reverse proxy setup in front of the emailproxy such that SSL is offloaded and the path is passed through . ie. the emailproxy will see this on port 8080
GET /oauth-handler/MicrosoftOauth2Redirect/code=0.AWcblahblah
host: myotherdomain.com
...
When I do the initial IMAP connection to the proxy I see this in the logs
...
Starting IMAP server at 0.0.0.0:1993 (unsecured) proxying outlook.office365.com:993 (SSL/TLS)
Starting SMTP server at 0.0.0.0:1587 (unsecured) proxying smtp.office365.com:587 (STARTTLS)
Initialised Email OAuth 2.0 Proxy - listening for authentication requests. Connect your email client to begin
Authorisation request received for myuser@mydomain.com (local server auth mode)
Email OAuth 2.0 Proxy Local server auth mode: please authorise a request for account myuser@mydomain.com
Please visit the following URL to authenticate account myuser@mydomain.com: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=8blahblah....redirect_uri=https%3A%2F%2Fmyotherdomain.com%2Foauth-handler%2FMicrosoftOauth2Redirect&scope=.....
...
I open the link in my browser and successfully authenticate as myuser@mydomain.com ... and get the ‘successful’ message in the browser. Then I see this failure in the emailproxy logs
2023-03-20 04:37:34: Local server auth mode (0.0.0.0:8080): closing local server and returning response https://myotherdomain.com/oauth-handler/MicrosoftOauth2Redirect/oauth-handler/MicrosoftOauth2Redirect?code=0.AWc.....&session_state=e3001234...
2023-03-20 04:37:34: Authorisation result error for myuser@mydomain.com - aborting login. OAuth 2.0 authorisation response is missing or does not match `redirect_uri`
Authorisation result error for myuser@mydomain.com - aborting login. OAuth 2.0 authorisation response is missing or does not match `redirect_uri`
What caught my eye was the double up of the path in the error message; ...om/oauth-handler/MicrosoftOauth2Redirect/oauth-handler/MicrosoftOauth2Redirect?cod.... and I was looking at that recent code change from issue 103 where the old line was this:
token_request['response_url'] = wsgiref.util.request_uri(environ)
and the new line is :
token_request['response_url'] = token_request['redirect_uri'].rstrip('/') + environ.get('PATH_INFO') + '?' + environ.get('QUERY_STRING')
I guess the new line looks like it would double up the path when your redirect_uri has a path component in it (like mine ; /oauth-handler/MicrosoftOauth2Redirect ) as PATH_INFO will have the path as well.
Anyway, I reverted emailproxy.py to use the old code line
token_request['response_url'] = wsgiref.util.request_uri(environ)
And tried again, and now the emailproxy works perfectly.
So my question is whether I've stuffed up my configuration or whether that new line doesn't work quite as intended.
token_request['response_url'] = token_request['redirect_uri'].rstrip('/') + environ.get('PATH_INFO') + '?' + environ.get('QUERY_STRING')