solara-ui 1.31.0__py2.py3-none-any.whl → 1.32.0__py2.py3-none-any.whl

solara/website/pages/documentation/advanced/content/10-howto/30-testing.md

@@ -5,20 +5,165 @@ description: Using solara you can test both the front and back end functionaliti
 
 # Testing with Solara
 
+When possible, we recommend to test your application without a browser. This is faster and more reliable than testing with a browser. Testing via a browser is more difficult to get right due to having to deal with two processes that communicate
+asynchronously (the Python process and the browser process).
+
+Only when you develop new components that rely on new frontend code or CSS do we recommend considering using a browser to test your component or application.
 
 ## Testing without a Browser
 
-We recommend using pytest to test the application logic of your Solara components. To get inspiration for writing tests that cover component logic and their interactions with existing components, refer to the [tests in the Solara repository](https://github.com/widgetti/solara/tree/master/tests).
+When testing a component or application without a browser, we recommend to use vanilla [pytest](https://docs.pytest.org/) to test the application logic.
+
+To get inspiration for writing tests that cover component logic and their interactions with existing components, refer to the [tests in the Solara repository](https://github.com/widgetti/solara/tree/master/tests).
+
+The following example demonstrates how to test a simple Solara component using pytest:
+
+```python
+import solara
+import ipyvuetify as v
+
+
+def test_docs_no_browser_simple():
+    clicks = solara.reactive(0)
+
+    @solara.component
+    def ClickButton():
+        def increment():
+            clicks.value += 1
+
+        solara.Button(label=f"Clicked: {clicks}", on_click=increment)
+
+    # rc is short for render context
+    box, rc = solara.render(ClickButton(), handle_error=False)
+    button = box.children[0]
+    assert isinstance(button, v.Btn)
+    assert button.children[0] == "Clicked: 0"
+    # trigger the click event handler without a browser
+    button.click()
+    assert clicks.value == 1
+    assert button.children[0] == "Clicked: 1"
+```
+
+Here we let Solara render the component into a set of widgets without a frontend (browser) connected.
+We check the resulting ipywidgets and its properties using `asserts`, as is standard with pytest.
+We also show how to trigger the click handler from the Python side using [`ipyvue`'s](https://github.com/widgetti/ipyvue) `.click()` method
+on the widget, again without requiring a browser.
+
+Run this test with pytest as follows:
+
+```bash
+pytest tests/unit/test_docs_no_browser_simple.py
+```
+
+
+### Finding a widget in the widget tree
+
+When widgets are embedded in a larger widget tree, it becomes cumbersome to find the widget you are looking for using `.children[0].children[1]...` etc. For this use case we can use the `rc.find` method to look for a particular widget. This API is inspired on the playwright API, and is a convenient way to find a widget in the widget tree.
+
+```python
+import solara
+import ipyvuetify as v
+
+
+def test_docs_no_browser_api_find():
+    clicks = solara.reactive(0)
+
+    @solara.component
+    def ClickButton():
+        def increment():
+            clicks.value += 1
+
+        with solara.Card("Button in a card"):
+            with solara.Column().meta(ref="my_column"):
+                solara.Button(label=f"Clicked: {clicks}", on_click=increment)
+            with solara.Column():
+                solara.Button(label="Not the button we need")
+
+    # rc is short for render context
+    box, rc = solara.render(ClickButton(), handle_error=False)
+    # this find will make the .widget fail, because it matches two buttons
+    # finder = rc.find(v.Btn)
+    # We can refine our search by adding constraints to attributes of the widget
+    button_locator = rc.find(v.Btn, children=["Clicked: 0"])
+    # basics asserts are supported, like assert_single(), assert_empty(), assert_not_empty()
+    button_locator.assert_single()
+    button = button_locator.widget
+    # .find calls can also be nested, and can use the meta_ref to find the right widget
+    # finder = rc.find(meta_ref="my_column").find(v.Btn)
+    button.click()
+    assert clicks.value == 1
+    rc.find(v.Btn, children=["Clicked: 1"]).assert_single()
+```
+
+By including keywords arguments to the `find` method, we can get more specific about the widget we are looking for.
+In the above example, a simple `.find(v.Btn)` would find two buttons, while `.find(v.Btn, children=["Clicked: 0"])` will find the button we are looking for. *(Note that this does require knowing about the internal implementation
+of the Button component: i.e. `solara.Button` creates a `v.Btn`, and the label argument causes the button having `children=["Clicked 0"]`)*.
+
+
+Because sometimes it is difficult to find a specific widget, we made is possible to attach meta data to a widget and
+use that to find widgets. Together with nesting (i.e. `.find(...).find(...)`) calls, this makes it easier to find the widget you are looking for in
+larger applications. In the above example we could have replaced the `.find(v.Btn, children=["Clicked: 0"])` with
+`.find(meta_ref="my_column").find(v.Btn)` to find the button we are looking for.
+
+Especially in larger application, adding meta data to widgets makes it much easier to find the widget you are looking for, as well
+as correlate the testing code back to the application code. Having unique meta_refs makes searching through your codebase and in your tests much easier.
+
+### Asynchronous updating of the UI
+
+When a [`solara.lab.task`](https://solara.dev/api/task) is executed, a new thread will spawn, which will likely update the UI somewhere in the future. We can wait for the UI to update using the `wait_for` method on the finder object. This method will poll the widget tree, waiting for the widget to appear. If the timeout is reached, the test will fail.
+
+```python
+import solara
+import solara.lab
+import ipyvuetify as v
+import time
+
+
+def test_docs_no_browser_api_thread():
+    clicks = solara.reactive(0)
+
+    @solara.component
+    def ClickButton():
+        @solara.lab.task
+        def increment():
+            # now we will wait for 0.3 seconds before updating the UI
+            time.sleep(0.3)
+            clicks.value += 1
+
+        with solara.Card("Button in a card"):
+            with solara.Column():
+                solara.Button(label=f"Clicked: {clicks}", on_click=increment)
+
+    # rc is short for render context
+    box, rc = solara.render(ClickButton(), handle_error=False)
+    finder = rc.find(v.Btn)
+    button = finder.widget
+    finder.assert_single()
+    finder.assert_not_empty()
+    assert button.children[0] == "Clicked: 0"
+
+    # clicking will now start a thread, so we have to wait/poll for the UI to update
+    button.click()
+
+    button_after_delayed_click = rc.find(v.Btn, children=["Clicked: 1"])
+    button_after_delayed_click.wait_for(timeout=2.5)
+```
 
 ## Testing with a Browser
 
+As mentioned in the introduction, when you develop new components that need frontend code or CSS, we recommend considering using a browser to test your component or application. Although these tests are slower to run and more
+difficult to get right, they may be crucial to ensure the correct rendering of your components or application.
+
+
 ### Installation
 
-Solara is using the `pytest-ipywidgets` pytest plugin together with [Playwright for Python](https://playwright.dev/python/) to test your widgets, components or applications using a browser, for both unit as well as integration tests.
+We recommend using the `pytest-ipywidgets` pytest plugin together with [Playwright for Python](https://playwright.dev/python/) to test your widgets, components or applications using a browser, for both unit as well as integration tests.
+
+Unit tests often test a single component, while integration (or smoke tests) usually tests your whole application, or a large part of it.
 
 To install `pytest-ipywidgets` and Playwright for Python, run the following commands:
 ```
-$ pip install "pytest-ipywidgets[solara]"  # or "pytest-ipywidgets[all]" if you also want to test with Jupyter Lab, Jupiter Notebook and Voila.
+$ pip install "pytest-ipywidgets[solara]"  # or "pytest-ipywidgets[all]" if you also want to test with Jupyter Lab, Jupyter Notebook and Voila.
 $ playwright install chromium
 ```
 
@@ -27,14 +172,13 @@ $ playwright install chromium
 The most convenient way to test a widget, is by including the `solara_test` fixture in your test function arguments. Here's an example:
 
 ```python
-# file tests/ui/test_widget_button.py
 import ipywidgets as widgets
 import playwright.sync_api
 from IPython.display import display
 
 def test_widget_button_solara(solara_test, page_session: playwright.sync_api.Page):
-    # this all runs in process, which only works with solara
-    # also, this test is only with pure ipywidgets
+    # The test code runs in the same process as solara-server (which runs in a separate thread)
+    # Note: this test uses ipywidgets directly, not solara components.
     button = widgets.Button(description="Click Me!")
 
     def change_description(obj):
@@ -57,10 +201,114 @@ pytest tests/ui/test_widget_button.py --headed # remove --headed to run headless
 ```
 
 
+### Testing state changes on the Python side with polling
+
+In the above example, an event in the frontend led to a state change on the Python side which is reflected in
+the frontend, so we could use Playwright to test if our event handler was executed correctly.
 
-# Testing in the main Jupyter Environments
+However, sometimes we want to test if a state changed on the Python side that has no
+direct effect on the frontend. A possible example is is a successful database write, or an update to a
+Python variable.
 
-In case you want to test your component in the main Jupyter environments (e.g., Jupyter Notebook, Jupyter Lab, Voila, and Solara) to ensure it renders correctly, use the `ipywidgets_runner` fixture to run code snippets. Here's an example:
+The following example uses a polling technique to check if a state change happened on the Python side.
+
+```python
+import ipywidgets as widgets
+import playwright.sync_api
+from IPython.display import display
+from typing import Callable
+import time
+
+
+def assert_equals_poll(getter: Callable, expected, timeout=2, iteration_delay=0.01):
+    start = time.time()
+    while time.time() - start < timeout:
+        if getter() == expected:
+            return
+        time.sleep(iteration_delay)
+    assert getter() == expected
+    return False
+
+
+def test_event_with_polling(solara_test, page_session: playwright.sync_api.Page):
+    button = widgets.Button(description="Append data")
+    # some data that will change due to a button click
+    click_data = []
+
+    def on_click(button):
+        # change the data when the button is clicked
+        # this will be called from the thread the websocket is in
+        # so we can block/poll from the main thread (that pytest is running in)
+        click_data.append(42)
+
+    button.on_click(on_click)
+    display(button)
+    button_sel = page_session.locator("text=Append data")
+    button_sel.click()
+
+    # we block/poll until the condition is met.
+    assert_equals_poll(lambda: click_data, [42])
+```
+
+### Testing state changes on the Python side with a Future
+
+Sometimes, state changes on the Python side emit an event that we can capture. In this case,
+we can use a `concurrent.futures.Future` to block until the state change happens. This is a more
+efficient way to wait for a state change than polling.
+
+```python
+import ipywidgets as widgets
+from concurrent.futures import Future
+import playwright.sync_api
+from IPython.display import display
+
+
+def future_trait_change(widget, attribute):
+    """Returns a future that will be set when the trait changes."""
+    future = Future()  # type: ignore
+
+    def on_change(change):
+        # set_result will cause the .result() call below to resume
+        future.set_result(change["new"])
+        widget.unobserve(on_change, attribute)
+
+    widget.observe(on_change, attribute)
+    return future
+
+
+def test_event_with_polling(solara_test, page_session: playwright.sync_api.Page):
+    button = widgets.Button(description="Reset slider")
+    slider = widgets.IntSlider(value=42)
+
+    def on_click(button):
+        # change the slider value trait when the button is clicked
+        # this will be called from the thread the websocket from solara-server
+        # is running in, so we can block from the main thread (that pytest is running in)
+        slider.value = 0
+
+    button.on_click(on_click)
+    display(button)
+    # we could display the slider, but it's not necessary for this test
+    # since we are only testing if the value changes on the Python side
+    # display(slider)
+    button_sel = page_session.locator("text=Reset slider")
+
+    # create the future with the attached observer *before* clicking the button
+    slider_value = future_trait_change(slider, "value")
+    # trigger the click event handler via the frontend, this makes sure that
+    # the event handler (on_click) gets executed in a separate thread
+    # (the one that the websocket from solara-server is running in)
+    button_sel.click()
+
+    # .result() blocks until the value changes or the timeout condition is met.
+    # If no value is set, the test will fail due to a TimeoutError
+    assert slider_value.result(timeout=2) == 0
+```
+
+
+### Testing in Voila, Jupyter Lab, Jupyter Notebook, and Solara
+
+In case you want to test your component in the multiple Jupyter environments (e.g., Jupyter Notebook, Jupyter Lab, Voila, and Solara) to ensure it renders correctly, use the `ipywidgets_runner` fixture to run code snippets. Here's an example:
 
 ```python
 import ipywidgets as widgets
@@ -98,7 +346,10 @@ Note that the function in the code will be executed in a different process (a Ju
 Because the function code executes in the kernel, you do not have access to local variables. However, by passing a dictionary as second argument
 to `ipywidgets_runner` we can pass in extra local variables (e.g. `ipywidgets_runner(kernel_code, {"extra_argument": extra_argument})`).
 
-## Limiting the Jupyter Environments
+These tests run slow, and are generally only recommended for ipywidgets authors that want to test if their library works in all Jupyter environments. We use these kinds of tests in libraries such as [ipyvue](https://github.com/widgetti/ipyvue), [ipyvuetify](https://github.com/widgetti/ipyvuetify), [ipyaggrid](https://github.com/widgetti/ipyaggrid), but should in general not be needed for most applications.
+
+
+### Limiting the Jupyter Environments
 To limit the ipywidgets_runner fixture to only run in a specific environment, use the `SOLARA_TEST_RUNNERS` environment variable:
 
  * `SOLARA_TEST_RUNNERS=solara pytest tests/ui`
@@ -109,7 +360,7 @@ To limit the ipywidgets_runner fixture to only run in a specific environment, us
 
 
 
-# Organizing Tests and Managing Snapshots
+### Organizing Tests and Managing Snapshots
 We recommend organizing your visual tests in a separate directory, such as `tests/ui`. This allows you to run fast tests (`test/unit`) separately from slow tests (t`est/ui`). Use the `solara_snapshots_directory` fixture to change the default directory for storing snapshots, which is `tests/ui/snapshots` by default.
 
 ```bash
@@ -123,7 +374,7 @@ To compare a captured image from a part of your page with the reference image, u
 For local development, you can use the --solara-update-snapshots flag to update the reference images. This will overwrite the existing reference images with the new ones generated during the test run. However, you should carefully review the changes before committing them to your repository to ensure the updates are accurate and expected.
 
 
-# Continuous Integration Recommendations
+### Continuous Integration Recommendations
 
 When a test fails, the output will be placed in a directory structure similar to what would be put in the `solara_snapshots_directory` directory but under the test-results directory in the root of your project (unless changed by passing `--output=someotherdirectory` to pytest).
 
@@ -141,22 +392,22 @@ In CI, we recommend downloading this directory using, for example, GitHub Action
 After inspecting and approving the screenshots, you can copy them to the `solara_snapshots_directory` directory and commit them to your repository. This way, you ensure that the reference images are up-to-date and accurate for future tests.
 
 
-# Note about the Playwright
+### Note about the Playwright
 
 Visual testing with solara is based on [Playwright for Python](https://playwright.dev/python/), which provides a `page` fixture. However, this fixture will make a new page for each test, which is not what we want. Therefore, we provide a `page_session` fixture that will reuse the same page for all tests. This is important because it will make the tests faster.
 
 By following these recommendations and guidelines, you can efficiently test your Solara applications and ensure a smooth developer experience.
 
-# Configuration
+### Configuration
 
-## Changing the Hostname
+#### Changing the Hostname
 
 To configure the hostname the socket is bound to when starting the test server, use the `HOST` or `SOLARA_HOST` environment variable (e.g. `SOLARA_HOST=0.0.0.0`). This hostname is also used for the jupyter server and voila. Alternatively the `--solara-host` argument can be passed on the command line for pytest.
 
-## Changing the Port
+#### Changing the Port
 
 To configure the ports the socket is bound to when starting the test servers, use the `PORT` environment variable (e.g. `PORT=18865`). This port and subsequent port will be used for solara-server, jupyter-server and voila. Alternatively the `--solara-port` argument can be passed on the command line for pytest for the solara server, and `--jupyter-port` and `--voila-port` for the ports of jupyter server and voila respectively.
 
-## Vuetify warmup
+#### Vuetify warmup
 
 By default, we insert an ipyvuetify widget with an icon into the frontend to force loading all the vuetify assets, such as CSS and fonts. However, if you are using the solara test plugin to test pure ipywidgets or a 3rd ipywidget based party library you might not need this. Disable this vuetify warmup phase by passing the `--no-solara-vuetify-warmup` argument to pytest, or setting the environment variable `SOLARA_TEST_VUETIFY_WARMUP` to a falsey value (e.g. `SOLARA_TEST_VUETIFY_WARMUP=0`).

solara/website/pages/documentation/advanced/content/15-reference/41-asset-files.md

@@ -34,3 +34,39 @@ Putting the `assets` directory 1 level higher than the `pages` directory avoids
 
 
 Although the `assets` directory can be used for serving arbitrary files, we recommend using the [static files](/documentation/advanced/reference/static-files) directory instead, to avoid name collisions.
+
+
+## Extra asset locations
+
+If for instance you are creating a library on top of Solara, you might want to have your own assets files, like stylesheets or JavaScript files.
+For this purpose, solara-server can be configured to look into other directories for assets files by setting the `SOLARA_ASSETS_EXTRA_LOCATIONS` environment variable.
+This string contains a comma-separated list of directories or Python package names to look for asset files. The directories are searched in order, after looking in the application specific directory, and the first file found is used.
+
+For example, if we run solara as:
+
+```
+$ export SOLARA_ASSETS_EXTRA_LOCATIONS=/path/to/assets,my_package.assets
+$ solara run solara.website.pages
+Solara server is starting at http://localhost:8765...
+```
+
+And we would fetch `http://localhost:8765/static/assets/my-image.jpg`, Solara-server would look for the file in the following order:
+
+1. `.../solara/website/assets/my-image.jpg`
+1. `/path/to/assets/my-image.jpg`
+1. `.../my_package/assets/my-image.jpg`
+1. `...site-package/solara/server/assets/my-image.jpg`
+
+## Recommended pattern for libraries to add asset locations
+
+If you are creating a library on top of Solara, and you want to programmatically add asset locations, you can do so by adding the following code to your library:
+
+```python
+import solara.server.settings
+import my_package.assets
+
+
+path = my_package.assets.__path__[0]
+# append at the end, so SOLARA_ASSETS_EXTRA_LOCATIONS can override
+solara.server.settings.assets.extra_locations.append(path)
+```

solara/website/pages/documentation/advanced/content/30-enterprise/10-oauth.md

@@ -133,8 +133,8 @@ You can also configure Solara to use our Fief test account. To do this, you need
 
 ```bash
 SOLARA_SESSION_SECRET_KEY="change me"  # required if you don't use the default test account
-SOLARA_OAUTH_CLIENT_ID="x2np62qgwp6hnEGTP4JYUE3igdZWhT-AvjpjwwDyKXU"  # found in the Auth0 dashboard Clients->General Tab->Secret
-SOLARA_OAUTH_CLIENT_SECRET="XQlByE1pVIz5h2SBN2GYDwT_ziqArHJgLD3KqMlCHjg" # found in the Auth0 dashboard Clients->General Tab->ID
+SOLARA_OAUTH_CLIENT_ID="x2np62qgwp6hnEGTP4JYUE3igdZWhT-AvjpjwwDyKXU"  # found in the Auth0 dashboard Clients->General Tab->ID
+SOLARA_OAUTH_CLIENT_SECRET="XQlByE1pVIz5h2SBN2GYDwT_ziqArHJgLD3KqMlCHjg" # found in the Auth0 dashboard Clients->General Tab->Secret
 SOLARA_OAUTH_API_BASE_URL="solara-dev.fief.dev"  # found in the Fief dashboard Tenants->Base URL
  # different from Solara's default
 SOLARA_OAUTH_LOGOUT_PATH="logout"
@@ -169,3 +169,12 @@ Please note that Python 3.6 is not supported for Solara OAuth.
 ### Wrong redirection
 
 If the redirection back to solara return to the wrong address, it might be due to solara not choosing the right default for `SOLARA_BASE_URL`. For instance this variable could be set to `SOLARA_BASE_URL=https://solara.dev` for the solara.dev server. If you application runs behind a subpath, e.g. `/myapp`, you might have to set `SOLARA_ROOT_PATH=/myapp`.
+
+
+### Wrong schema detected for redirect URL
+
+Solara needs to give the OAuth providers a redirect URL to get back to your Solara application after navigating to the OAuth provider website. For our documentation server, we ask the OAuth provider to redirect to `https://solara.dev/_solara/auth/authorize`. The protocol part (`https`) and the domain name part (`solara.dev`) or this URL is constructed from the request URL (what the browser sends to the server).
+
+If you are running Aolara behind a reverse proxy server (like nginx), make sure that the `X-Forwarded-Proto` and `Host` headers are forwarded correctly so Solara can construct the correct redirect URL to send to the OAuth provider.
+
+See our [self hosted deployment](https://solara.dev/documentation/getting_started/deploying/self-hosted) for more information on how to configure your reverse proxy server.

solara/website/pages/documentation/advanced/content/40-development/10-setup.md

@@ -11,7 +11,7 @@ Assuming you have created a virtual environment as described in [the installatio
 
     $ git clone git@github.com:widgetti/solara.git
     $ cd solara
-    $ pip install ".[dev,documentation]"  # documentation is optional
+    $ pip install -r requirements-dev.txt
 
 
 ## Running Solara server in auto restart mode

solara/website/pages/documentation/faq/content/99-faq.md

@@ -74,3 +74,30 @@ Voila and Solara set the following environment variables (based on the CGI spec)
 
 Jupyter Notebook/Lab/Server do not set these variables. With this information,
 it should be possible to recognize in which environment you are running in.
+
+
+## I cannot find or run `solara` from the command line
+
+
+On Linux or OSX you might see
+
+```
+$ solara
+command not found: solara
+```
+
+On Windows you might see
+
+```
+C:Users\myusername> solara
+solara: The term 'solara' is not recognized as the name of a cdlet, function,
+script file, or operable program.
+```
+
+The solara command before version 1.30 was installed with the package `solara`, but now it is installed with the package `solara-server`.
+
+If you upgrade from an older version to 1.30 or later, the order in which pip installs packages can cause the `solara` command to be uninstalled. To fix this, reinstall the `solara-server` package:
+
+```bash
+$ pip install solara-server --force-reinstall
+```

solara/website/pages/documentation/getting_started/content/02-installing.md

@@ -89,7 +89,7 @@ $ pip install solara-air-gapped/*.whl
 The `solara` package is a meta package that installs all the necessary dependencies to get started with Solara. By default, we install:
 
   * [`pip install "solara-ui[all]"`](https://pypi.org/project/solara-ui)
-  * [`pip install "solara-server[starlette,dev]"`](https://pypi.org/project/solara-ui) -
+  * [`pip install "solara-server[starlette,dev]"`](https://pypi.org/project/solara-ui)
 
 Note that the solara (meta) package will pin exact versions of solara-ui and solara-server, which ensures you always get compatible version of the subpackages.
 For more flexibility, and control over what you install, you can install the subpackages directly.
@@ -125,7 +125,7 @@ The `solara-server` packages supports the following optional dependencies:
 ### The `pytest-ipywidgets` package
 
 This package is a plugin for pytest that lets you test ipywidgets with playwright. It is useful for testing your ipywidgets or solara applications in a (headless) browser.
-See [Our testing documentation](https://solara.dev/docs/advanced/testing) for more information.
+See [Our testing documentation](https://solara.dev/documentation/advanced/howto/testing) for more information.
 
  * `pip install "pytest-ipywidgets"` - Minimal installation for testing ipywidgets.
  * `pip install "pytest-ipywidgets[voila]"` - The above, with a compatible version of voila.

solara/website/pages/documentation/getting_started/content/07-deploying/10-self-hosted.md

@@ -226,31 +226,47 @@ configuration would be:
 server {
     server_name widgetti.io;
     listen 80
-    location /solara/ {
+    location / {
             # the local solara server (could be using Starlette/uvicorn)
             proxy_pass http://localhost:8765/;
 
             proxy_set_header Host $host;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-            proxy_set_header X-Script-Name /solara;  # informs solara to produce correct urls
+            proxy_set_header X-Forwarded-Proto $scheme;
 
             proxy_http_version 1.1;
             proxy_set_header Upgrade $http_upgrade;
             proxy_set_header Connection "upgrade";
             proxy_read_timeout 86400;
     }
+
+    # If you do not host solara on the root path, you can use the following
+    # location /solara/ {
+    #        ...
+    #        proxy_set_header X-Script-Name /solara;  # informs solara to produce correct urls
+    #        ...
+    # }
 }
 ```
 
-Note that if we use `location /` instead of `location /solara/`, we can skip the `proxy_set_header X-Script-Name /solara` line.
-
 An alternative to using the `X-Script-Name` header with uvicorn, would be to pass the `--root-path` flag, e.g.:
 
 ```
 $ SOLARA_APP=sol.py uvicorn --workers 1 --root-path /solara -b 0.0.0.0:8765 solara.server.flask:app
 ```
 
+In the case of an [OAuth setup](https://solara.dev/documentation/advanced/enterprise/oauth) it is important to make sure that the `X-Forwarded-Proto` and `Host` headers are forwarded correctly.
+If you are running uvicorn (the default if you use `solara run ...`) you will need to configure uvicorn to accept these headers using e.g.:
+
+```bash
+export UVICORN_PROXY_HEADERS=1
+export FORWARDED_ALLOW_IPS = "127.0.0.1"  # If your solara-server can *only* be reached by the proxy, you can set it to "*", otherwise put in the IP of the reverse proxy
+```
+
+Make sure you replace the IP with the correct IP of the reverse proxy server (instead of `127.0.0.1`). If you are sure that only the reverse proxy can reach the solara server, you can consider
+setting `FORWARDED_ALLOW_IPS="*"`.
+
 ## Docker
 
 There is nothing special about running Solara in Docker. The only things you probably need to change is the interface the server binds to.

{solara_ui-1.31.0.dist-info → solara_ui-1.32.0.dist-info}/METADATA

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: solara-ui
-Version: 1.31.0
+Version: 1.32.0
 Dynamic: Summary
 Project-URL: Home, https://www.github.com/widgetti/solara
 Project-URL: Documentation, https://solara.dev
@@ -152,7 +152,7 @@ By building on top of ipywidgets, we automatically leverage an existing ecosyste
 
 Visit our main website or jump directly to the introduction
 
-[![Introduction](https://dabuttonfactory.com/button.png?t=Introduction&f=Open+Sans-Bold&ts=20&tc=fff&hp=45&vp=12&c=8&bgt=unicolored&bgc=f19f41)](https://solara.dev/documentation)
+[![Introduction](https://dabuttonfactory.com/button.png?t=Introduction&f=Open+Sans-Bold&ts=20&tc=fff&hp=45&vp=12&c=8&bgt=unicolored&bgc=f19f41)](https://solara.dev/documentation/getting_started/introduction)
 [![Quickstart](https://dabuttonfactory.com/button.png?t=Quickstart&f=Open+Sans-Bold&ts=20&tc=fff&hp=45&vp=12&c=8&bgt=unicolored&bgc=f19f41)](https://solara.dev/documentation/getting_started)
 
 *Note that the solara.dev website is created using Solara*