Logging in to OctoPi when in an iFrame (even with auto-login)

Get Help Networking
1

What is the problem?

When putting OctoPi in an iFrame, the login page just loops. Turning on autoLogin (with a local IP) goes further, but results in a 403 when accessing /api/settings, preventing the UI from fully loading.
To note, this is a direct iFrame configuration, on a 'dashboard' monitor that will have 4 iFrames (for 2 PIs):

  • 1 iFrame (per pi) will be the webcam stream (these work as they don't require authentication)
  • 1 iFrame (per pi) will be to the 'temp' page to monitor extruder/hotbed temps and print progress (these don't work)

What did you already try to solve it?

  • Configured the iFrame page to use direct IP addresses (both http and https)
  • Configured a reverse proxy in front of both PIs (with SSL termination)
  • Reviewed the 'developer console' and system logs to confirm errors being generated
  • Have tried a variety of cookie configuration options (based on various searches) with 'samesite and secure), with no change in behavior

Have you tried running in safe mode?

  • Yes, same results

Did running in safe mode solve the problem?

  • No

Systeminfo Bundle

Additional information about your setup

  • Both systems are running OctoPi 1.9.3
  • Both are properly accessible when accessing directly
  • Reverse proxy is flexible between client->pi, client->haproxy->pi and client->haproxy->apache2->pi
2

Did you find any errors here? What did you find?

3

I thought I put that in here but must have edited it out along the way.
The only log entries I could find that were applicable were tornado.log entries showing the 403 access to the /api/settings endpoint.

2024-04-20 16:02:22 - tornado.access - INFO - 200 POST /api/login (<ip address>) 32.36ms
2024-04-20 16:02:22 - tornado.access - INFO - 200 POST /api/login (<ip address>) 32.84ms
2024-04-20 16:02:22 - tornado.access - WARNING - 403 GET /api/settings (<ip address>) 291.05ms
4

couple of related reports of this

5

Thank you for your reply. I read through all of those issues (and more), before posting this thread. As most of those were older threads that I didn't want to re-open, none of them had a viable solution. Reviewing these threads, to ensure I hadn't missed a possible solution, I did neglect to mention as part of 'steps of troubleshooting', that I did enable the iFrame embedding option, and I also enabled the CORS option under the API. As the login prompt was coming up, prior to enabling the auto-login, and the UI is trying to load (bypassing the login prompt), after having turned on the autologin functionality that seems to be working properly. It's the API endpoint that is currently causing the issue, since the /api/settings endpoint is returning a 403 (with autologin enabled), it seems as though it's not honoring the autologin setting and expecting some other authentication validation to be present to pass the request through, or it's "seeing" a different IP other than 127.0.0.1/8, ::1.128, and my local network IP range, which are the configured localNetworks values.

For further information, the accessControl block is configured as below:

accessControl:
  autologinAs: <my user>
  autologinLocal: true
  enabled: true
  localNetworks:
  - <My internal network Class-C range>
  - 127.0.0.1/8
  - ::1/128

The api section does have the 'allowCrossOrigin' option enabled.

Unsure if this is playing in to this issue, the cookies section is currently as follows:

cookies:
  samesite: lax
  secure: false

However, based on other threads, I've tried 'none' for the samesite option, as well as toggled secure to true (especially when I had the reverse proxy in-place).

Also, may be worth noting. A number of the similar threads are specifically trying to embed OctoPi in to a HomeAssistant dashboard, I am not. I have a Linux machine running a 'dashboard' monitor where it's simply running a browser pointing at a local html file on the system that is configured with the 4 previously mentioned iFrames.

6

As I was typing the previous reply I decided to try something different, which may not be an option for everyone, but it solved my issue.

I configured a new subdomain that hosts my iframe base html file, instead of having it reside locally on the dashboard system. I then took both OctoPi's and put them back behind the reverse proxy, so the base domain is the same for both the iframe page and the OctoPi endpoint. That was able to work past the cross-domain issue, as well as made the /api/settings endpoint happy (which I'm guessing was having issues with cross-domain, without actually saying it), and the UIs came up properly.

The one setting that needed to be changed is to ensure my external IP is registered as a valid auto-login source as I'm now coming through my proxy and not directly from my workstation. I then put the endpoints behind OIDC to ensure the systems aren't freely accessible to the world.

As mentioned, this may not be a viable option for everyone, but hopefully it can help someone stuck with similar hurdles.

1 Like
7

To truly give the best solution for everyone, it seems @Matte figured this out in the other thread.

You need this in config.yaml.

server:
  cookie:
    samesite: none
8

Leaving this for the google lead people here:

image.jpg1520×1524 252 KB

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.