OAuth redirect uri

Panel
, ,
1

I can no longer get panel (0.14.4) to work with oauth. Previously had it running in an older version, but won’t work anymore now. I am serving the app roughly as follows:
panel serve script.py --allow-websocket-origin="*" --port=5008 --oauth-provider="azure" --oauth-key="*" --oauth-secret="*" --oauth-extra-params="{'tenant':'*'}" --cookie-secret="*" --oauth-redirect-uri="*"
There are a few situtations I have tried, that fail in different ways

  1. The --oauth-redirect-uri includes the script i.e. mysite.com/script
    Loading the page immediately redirects me to mysite.com/script/login?next=%2f which gives a 404 not found error.
  2. The --oauth-redirect-uri is only the base webaddress i.e. mysite.com:
    Where the information all matches those set in the app registration. When attempting to access my app, it properly redirects me to azure login. After logging in however, azure fails to redirect me back to my app. It appears to redirect to mysite.com/login, which is not a valid link when serving script.py
  3. I launch my app from login script i.e. panel serve login.py …
    On accessing the site I immediately get a too many redirects prompt followed by 502 bad gateway.

Does anyone have any insight on what I might be doing wrong?

2

I’ve tried using Github as oauth provider and everything worked fine. The issue seems to be specific to azure/azurev2. Running --log-level=debug, I see authentication goes correctly and I get the right tokens. Things seem to go wrong during redirect, but I cannot tell how. Judging by the debug output, mysite.com/login should indeed be a correct URL (and is indeed handled correctly with github), but with azure I only get a 502 page. Looking at the cookies, when I use azure I still only see the ‘panel-oauth-state’ cookie on the page, even though the headers do contain the new cookies (user, access_token and id_token)…

1 Like
3

Hi @sander

Try reporting this as a bug on Github. Please also take a look at the closed and open issues containing azure. There might be a hint there somewhere.

4

Hi Marc,
Thanks for the response. I did end up figuring it out; it seems the header was too big for the reverse proxy. Increasing the buffer size fixed it.

2 Likes
5

Thanks @Sander for coming back and sharing the solution.

1 Like
6

@Sander Could you share your buffer size values for reverse proxy?

Increasing buffer size worked for me for some time, but at the moment it doesn’t help me anymore. I am wondering if I am missing some configuration or maybe I face some different problem.

7

I ended up setting the following values:

proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;
1 Like