Solara•17mo ago

Force solara to use https in redirect uris

Using Chrome's Dev Tools, I observed the following network requests after clicking the login button in my application:

Initial Login Request:

https://example.com/_solara/auth/login?redirect_uri=https%3A//example.com/return_to_path

https://example.com/_solara/auth/login?redirect_uri=https%3A//example.com/return_to_path

This request looks correct as it uses https.

Authorization Request to Okta:

https://my-okta-domain.oktapreview.com/oauth2/v1/authorize?response_type=code&client_id=MY_CLIENT_ID&redirect_uri=http%3A%2F%2Fexample.com%2F_solara%2Fauth%2Fauthorize&scope=openid+profile+email&state=MY_STATE&nonce=MY_NONCE

https://my-okta-domain.oktapreview.com/oauth2/v1/authorize?response_type=code&client_id=MY_CLIENT_ID&redirect_uri=http%3A%2F%2Fexample.com%2F_solara%2Fauth%2Fauthorize&scope=openid+profile+email&state=MY_STATE&nonce=MY_NONCE

The issue here is that the

redirect_uri

redirect_uri

parameter is using

http

http

instead of

https

https

.

Is there a way to force a solara application to use

https

https

scheme/protocol for redirect URIs (for auth). I tried setting

SOLARA_SESSION_HTTPS_ONLY=True

SOLARA_SESSION_HTTPS_ONLY=True

and

SOLARA_BASE_URL=https://example.com/

SOLARA_BASE_URL=https://example.com/

but I still see

http

http

. Maybe I could mount my solara app to a Starlette app with an added

HTTPSRedirectMiddleware

HTTPSRedirectMiddleware

middleware?

MaartenBreddels•8/19/24, 8:28 PM

Strange, because everywhere at https://github.com/widgetti/solara/blob/master/packages/solara-enterprise/solara_enterprise/auth/starlette.py it uses SOLARA_BASE_URL (via settings.main.base_url), so if that env var is set, I don't understand why it still takes http.
A few ideas: make sure you remove cookies and cache (i've once had an old session cookie act weird).
print out in the solara source code as a sanity check

GitHub

solara/packages/solara-enterprise/solara_enterprise/auth/starlette....

A Pure Python, React-style Framework for Scaling Your Jupyter and Web Apps - widgetti/solara

CyrusOP•8/19/24, 8:54 PM

I tried incognito mode with fresh cookies and also verified that prints the correct base url. Deploying locally I can modify solara source code to also print in the endpoint and it prints something like this

CyrusOP•8/19/24, 8:59 PM

Given this scope (with 'scheme': 'http') I think then here my url gets defaulted to have 'http' sheme?

CyrusOP•8/19/24, 9:57 PM

Shouldn't the login endpoint here be using instead of ? When I set SOLARA_BASE_URL then correctly updates, while doesn't

MaartenBreddels•8/20/24, 7:57 AM

Yes, you may be right!
I am pretty sure that is a bug, and I'll open an issue (if you don't)
However, if the proxy server is configured correctly, this should not be a problem, I think is not set in your reverse proxy

MaartenBreddels•8/20/24, 7:57 AM

see https://solara.dev/documentation/advanced/enterprise/oauth and https://solara.dev/documentation/getting_started/deploying/self-hosted

Using OAuth in your Solara app

Open Authorization can be readily integrated into your Solara applications via the Solara-Enterprise package.

Deploying and hosting your own Solara app

Solara is compatible with many different hosting solutions, such as Flask, Starlette, FastAPI, and Voila.

CyrusOP•8/20/24, 3:12 PM

In my case the app should not be going through a proxy, because it's hosted within a VPC but maybe the load balancer can affect headers and what not. I am happy to open an issue about the bug!

CyrusOP•8/20/24, 3:58 PM

@MaartenBreddels I created an issue

MaartenBreddels•8/20/24, 4:24 PM

What load balancer are you using (that should behave as a reverse proxy)

CyrusOP•8/20/24, 5:08 PM

It is a AWS Application Load Balancer (ALB) configured to listen for https requests (the security group only accepts https). I am not too knowledgeable about infra but I think the header should automatically be forwarded in our setup to indicate the protocol used by the client.

MaartenBreddels•8/20/24, 5:39 PM

@mariobuikhuizen maybe you have an idea how this can happen (i can update you tomorrow)

MaartenBreddels•8/20/24, 5:39 PM

@Cyrus could you print out the headers you get from any request? I'd like to see what headers ALB sends

MaartenBreddels•8/20/24, 5:40 PM

similar to the print out you did above (if it contains sensitive data, you can send it to maartenbreddels@widgetti.io)

MaartenBreddels•8/20/24, 5:42 PM

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/x-forwarded-headers.html they should be in there

HTTP headers and Application Load Balancers - Elastic Load Balancing

Learn about the X-Forwarded request headers for Elastic Load Balancing.

CyrusOP•8/20/24, 10:02 PM

I was able to grab the OAuth2 authorization request/response headers from chrome dev tool. The request chain starts when I click on my app's Login button (which href's to ).

The first request is (using placeholders to hide some stuff):

CyrusOP•8/20/24, 10:04 PM

you can see the in the request header but then

http

http

in the response location redirect_uri, which doesn't align with the redirect uris allowed in the app, thus breaking the auth flow

MaartenBreddels•8/20/24, 10:15 PM

I mean the request headers solara sees, because the load balancer will add extra headers that you don’t see in the dev console, you need to modify the Python code with a print statement for that like you did above

CyrusOP•8/20/24, 10:20 PM

Ah, to print

request

request

before I just modified solara source code locally. For the remote version connected to the ALB I can try embedding my solara app in Starlette and then overwriting the route to point to a custom endpoint in the app with logging statements. Will let you know how it goes.

CyrusOP•8/21/24, 6:50 AM

OK, so with my own custom function I was able to fix the problem by implementing the bug fix suggested in the issue. I was also able to add print statements and verify that indeed is using

http

http

compared to . I also printed headers confirming that the ALB is forwarding things correctly (with ):

So it looks like it was the bug that we discussed above

CyrusOP•8/21/24, 2:10 PM

@MaartenBreddels Would you like me to create a (tiny) PR for this?

MaartenBreddels•8/21/24, 2:11 PM

Hi Cyrus, no thanks, not yet, I need to dig into starlette a bit to see why this does not work, because everything is setup correctly

MaartenBreddels•8/22/24, 3:12 PM

I think this is something that uvicorn should be told to do..

MaartenBreddels•8/22/24, 3:12 PM

looking at https://www.uvicorn.org/
We can define UVICORN_PROXY_HEADERS=1

Uvicorn

The lightning-fast ASGI server.

MaartenBreddels•8/22/24, 3:12 PM

could you try that?

MaartenBreddels•8/22/24, 3:13 PM

it is documented here: https://solara.dev/documentation/getting_started/deploying/self-hosted

Deploying and hosting your own Solara app

Solara is compatible with many different hosting solutions, such as Flask, Starlette, FastAPI, and Voila.

MaartenBreddels•8/22/24, 5:35 PM

looking at https://github.com/encode/starlette/issues/692 it seems like only ALLOW_FORWARDED_IPS is needed

Monty Python•8/22/24, 5:35 PM

shangxiao

<:issue_closed_completed:979047130847117343> [encode/starlette] Consider using X-Forwarded-Proto with HTTPSRedirectMiddleware

It would be handy if

HTTPSRedirectMiddleware

HTTPSRedirectMiddleware

had an option to use the header for redirecting on platforms like Heroku.

Created

•

10/28/19, 9:52 AM

CyrusOP•8/22/24, 8:28 PM

setting didn't work. The redirect uri based on reverted back to

http

http

CyrusOP•8/22/24, 8:41 PM

Maybe it should be ?

CyrusOP•8/22/24, 8:41 PM

https://www.uvicorn.org/settings/

Settings - Uvicorn

The lightning-fast ASGI server.

CyrusOP•8/22/24, 9:06 PM

It worked!! I definitely think a note about should be documented in the solara auth page (or even set by default to within solara server?)

MaartenBreddels•8/23/24, 9:32 AM

https://github.com/widgetti/solara/pull/745

Monty Python•8/23/24, 9:32 AM

maartenbreddels

<:pull_open:882464248721182842> [widgetti/solara] feat: give warnings if we detect a possible proxy/uvicorn misconfiguration

Based on x-forwarded-host and x-forwarded-proto headers, and asgi scope data we can detect a possible misconfiguration of the proxy/uvicorn

We noticed many people struggle to configure this right. The documentation is also made consistent with better insights into the possible misconfigurations.

Related to #740

Created

•

8/23/24, 9:31 AM

MaartenBreddels•8/23/24, 9:33 AM

Could you maybe check this branch and see if this gives you good error messages/hints?

CyrusOP•8/23/24, 1:41 PM

Sure, will test now and reply in the issue.

CyrusOP•8/23/24, 2:24 PM

Looks like it worked (see issue)