ElementWeb - can't download files / invalidate user session

[Maypul]

Steps to reproduce

1. Using Element Web, upload file to chat that is not a picture, for example .msg or .doc
2. Try to download said file via web
3. Download fails

Authentication is done via OAUTH (Authelia), and when I try to download the file, it also invalidates my session. If I log in to server for example via desktop client (windows) or upload/download picture it downloads without any issue. It seems to affect attachements that are not previewable on web.

The moment I click download button following errors happen in browser:
https://prnt.sc/Lt7jGVTfCSKL and session gets invalidated. Censored link is to web chat (element).

I though it could by CSP or other policies from my proxy (Traefik) but when I disabled them it still would error with same warnings.

Outcome

What did you expect?

File does download successfully via web and does not invalidate user session.

What happened instead?

File does not download successfully via web and does invalidate user session.

Operating system

ElementWeb in Docker system

Browser information

Firefox 106.0.5 and Chrome Canary 110.0.5431.0

URL for webapp

Private server, latest tag as of 21/11/2022

Application version

Element 1.11.14 Olm version: 3.2.12

Homeserver

Local server, Synapse Matrix, also latest tag

Will you send logs?

No

[t3chguy]

This looks like an issue with the OAuth wrapper not letting the app iframe to the script it needs called bundles/<hash>/usercontent.js

[Maypul]

I am no expert, is there anything that I could possible reconfigure from my side or it that possibly upstream issue? I do not think I block anything from my oauth provider (authelia) and disabled anything that could possibily interact from Traefik side, possibly only web server serving Element is left in the equasion with its settings but I can't see anything in Authelia's config that could block it.

[t3chguy]

Likely the issue is due to iframe sandboxing, the usercontent script will be fetched without your Authelia creds due to the sandbox. You'll likely need to whitelist things until they work. Running Element behind Authelia is not a supported scenario. Why do you run an app which is entirely client-side behind an auth proxy? That doesn't magically protect your localStorage & IndexedDB so if an attacker has those but not your SSO then they can just move them to a different Element instance and they'd work. Local system security is far more critical with client-side apps.

[Maypul]

@t3chguy I use Authelia as an user povider to Synapse server, so user which logs to Element chat via web, logs only using Authelia and seamslessly loads to Synapse server with their account. They can also use the same credentials on the desktop client.

I have found how to make it work, you need to set same_site in Authelia config to none and it does not crash and allows to download files but I understand that 'lax' which was default, is more secure and recommended default regardless.

Since this is private server, why do not keep it behind Authelia ACL anyway since the user will need to log into it once anyway so it just adds layer so others do not see Element's login page but Authelia's if they enter the chat link, but the user still types credentials once.

The other way around to make it work, it to move Element chat outside Authelia ACL, enable Element's login page and here give an option to log in with Authelia, then the same_site can be left as lax and it does work but the user the user also needs to click an additional button to log in and the site is not behind Authelia's ACL. From my testing only downloading did not work so far with this setup, in the future I would like to see an option to have Element working fully behind Authelia with 'lax' option enabled, this is first time I have encountered this issue and thank you for pointing it out it helped me to make it work!

[t3chguy]

why do not keep it behind Authelia ACL anyway

Because it causes issues around more critical security issues like iframe sandboxing which prevent XSS. One could take any Element Web e.g. app.element.io and point it at your Authelia-guarded Matrix HS without having those issues. You should if possibly only guard the entrypoint (index.html) if you want the smoother single-login mechanism, without potential to impact things which rely on full sandboxing of other app resources

[andybalaam]

@Maypul is it helpful to keep this issue open, or is your question answered?