Opening the settings menu causes error.

[BobHassok]

When I try to open the settings menu, (http://localhost/settings) I get this error. https://i.imgur.com/gogKZhP.png

Alternatively, when I make a fresh container and open the settings pane, it loads, but if I make any changes and save, it gives me an error 419.

I assume my PHP is botched and I'm probably going to have to make a brand new Heimdall instance?

[esbeeb]

This happens to me as well - the error 419 - 2/3 of the time, when I try to save any created Heimdall application button. This problem happens to me ONLY when in a docker container. The problem does not happen when Heimdall is a native install - not in a container. Note that these 419 errors occur whether the docker container is in docker-ce 20.10.18 (in Debian 11), or podman 4.2.1.

I highly suggest a native install of Heimdall. I put some rough install instructions for a native/non-docker install of Heimdall here. BTW: your Heimdall will also be about 20x more performant (opening and closing any menu), when not run in docker!

[tophee]

@esbeeb thanks for sharing your workaround.

your Heimdall will also be about 20x more performant (opening and closing any menu), when not run in docker!

What do you have to back up that statement?

[BobHassok]

Sadly, I much prefer having it run in Docker. This issue seems to have begun in the last 2-3 months with the newest image from here and from LinuxServer.io.

[esbeeb]

@esbeeb thanks for sharing your workaround.

your Heimdall will also be about 20x more performant (opening and closing any menu), when not run in docker!

What do you have to back up that statement?

I set up a VM (guest OS: debian 11, host os: Linux Mint Debian edition 5 - LMDE5), and installed Heimdall both in docker-ce, and just a manual install as above. I was able to start both Heimdalls at the same time, both in the VM, just listening on slightly different ports (the docker container, listening with the default of :8080, then with my manual "artisan" command, I specified :8082 instead). The VM is of type QEMU/KVM, as accessed from Virtual Machine Manager. This is on AMD64 hardware.

From the host OS' web browser, I visited the Heimdalls at both links (same URL both times, different ports), each in its own browser tab. As to application buttons already created: those instantaneously launch the links in new browser tabs. That's lightning fast: the experience end users would have - using application buttons already set up.

The 20x slowdown is when an admin user of Heimdal opens any menus for adding/editing application buttons, etc. Everything goes from instantaneously (like 100ms) to about 8 seconds, if it was done in Docker. That's just to open the menus!! Then when saving a newly-created, filled-out dialog for a new application button, 2 times in 3 if it was in docker only, I got the highly annoying "error 419", and the application button wouldn't create!

Was the RAM exhausted in either the host OS or guest? No. Plenty of RAM. How about CPU? The CPU was almost totally idle both in host and guest. During that 8ish-second pause while docker acted slowly: no CPU spike is seen in an htop, in the guest OS. There are also no disk I/O bottlenecks, as seen with iotop.

It's as if docker doesn't take advantage of the CPU and use it fully. What is docker doing, not using the CPU which it could?

[BobHassok]

I've completely discarded my previous Heimdall setup and made a fully new container. When I save a setting it will save, however I have to close the browser tab and reconnect to edit another setting. If I don't close the tab and start again, I'm once again given error 419. For example if I add a url in Heimdall, then save it, I cannot add another URL unless I close the tab and open settings again, or else I get error 419. The same is true if I try to edit users, which tab to open in, default search bar, etc.

[esbeeb]

@esbeeb thanks for sharing your workaround.

I've added a sample nginx conf file here, so as to get systemd goodness to start heimdall at boot time.

Based on this info (which is admittedly not squeaky-clean for novice users, however intermediate to advanced linux admins would be able to wing it), it's possible that the Heimdall documentation could be expanded to include a non-docker method of installation - at least in the case of Debian 11, combined with nginx and php7.4.

[KodeStar]

Looking at that error message you deleted google as an option from the searchproviders.yml but it is what was set as the default provider. You could add google back to the list (look in search providers under Discussions), then go into settings, change the default to something else, then delete it again.