Text Diff module not working when using reverse proxy (with authentik)

[gitmotion]

Describe the bug

Text Diff module does not load anymore. Noticed it works if I access from the internal ip but not from the reverse proxy. I've also tried adding it directly to npm with a custom location mapped to the assests folder and container but still gives me the same error.

What happened?

It should load as it does on the internal ip

System information

• Docker
• Nginx Proxy Manager
• Authentik

Where did you encounter the bug?

Self hosted

[Fintanw23]

Wow exactly my issue and setup! Very annoying as text-diff is 90% of what i use this container for :(

[gitmotion]

ah so i'm starting to believe this is a CORS issue, since having an authentication provider like authentik redirects from the authentik URL. got this error this when trying to access my local version vs external version (instead of internal ip)

• this still doesn't explain why the other modules work just fine though so i'm sure there's a fix in there that could be made.
• it seems like an issue with how authentik handles the routing possibly

@Fintanw23 i'm not sure exactly how but somehow i fixed this lol with the following:

• something i tried was logging out of authentik and then logging back and in hard refreshing ittools. it seems like there's a lot of caching going on. seems like once you get the file to load it stores it locally and allows it to work fine?
• sorry i can't seem to pinpoint how i fixed it lol but i did something like this to get it to load, hope that helps

[gitmotion]

@Fintanw23 did a little more digging and found that the problem was with authentik(for me), the fix for me was to set /assets/* in the unauthenticated paths in the provider settings that you set up for your it-tools instance within authentik. hope that works for you!

in cloudflare, you might also need to set a caching rule to bypass cache for your subdomain/domain either sitewide or that specific host and clear the cache in Caching > Configuration > Purge Everything

[AlexD0TNET]

@gitmotion I ran into the same problem, and while adding /assets/* to the Unauthenticated Paths does fix this issue, it seems to also pretty much disable authentication. Try opening your it-tools like this, from a browser which is not logged into authentik: https://$DOMAIN$/assets/test

When I tested it, it showed me a 404 (because /assets/test does not exist) but completely bypassed the forward authentication via authentik. From this 404 screen you are able to use it-tools freely, as long as you don't refresh the page.

I would therefore kindly ask you to consider re-opening your issue

Edit: this is strange, but after removing the /assets/* workaround from authentik, my instance is now secure against this /assets/test 'hack' but both text-diff and max address lookup still work fine. Maybe try this on your setup as well? I would be interested to hear if it behaves the same.

Edit 2: One day later, text-diff and Mac-address-lookup went back to not working reliably for me without the authentik change. At least not by just clicking the tile. Manually navigating to /text-diff did just work however..

[Loigzorn]

My setup is exactly the same as described my @gitmotion. IT-Tools runs inside a docker container and is exposed over Nginx Proxy Manager (NPM). To project the site from public access I use a authentik Proxy.

I encountered the behaviour of the text-diff tool not loading recently. For me a fix was to disable caching of the Nginx Proxy Manger:

Additional I've set the Launch URL of the Application of authentik to the URL where IT-Tools are hosted.

After that I hard-reloaded the page to empty the cache and to re-authenticate with authenitk.

Not sure if this is a permanent fix. Also to set the Launch URL of authenik shouldn't be required.

Let me know if this could resolve the bug for one of you

[gitmotion]

@AlexD0TNET @Loigzorn interesting 🤔 i already have caching off on my NPM but the issue does seem related to caching within it-tools from my own experience. my setup might be a little different because i just created one main entrypoint to authentik, instead of creating separate proxy hosts for each service in NPM, and then let authentik handle the rest. but in theory i believe it should be the same underlying issue.

the issue

my basic understanding is that it might be because it-tools is presenting the built-in cached version on load but without authentik actually authenticated/authentik-ed (or expired auth) so it can't access /assets. so it looks like you should be able to access the tool but in reality you should be seeing the authentik screen on first load instead. (aka the "expired auth cached state")

• i think the reason why some tools work and some tools don't (like text-diff and mac-address-lookup) is because the one's that work is using just javascript without imports. but the text-diff tool is importing the monaco-editor, which you need to be authentik-ed to access (if it's not already cached)
• which is also why it works when you set the unauthenticated paths in authentik. even if your token was expired, because /assets was set as an unauthenticated path the token validity isn't required / bypasses authentication to access that resource in the "expired auth cached state"
• also why everything works just fine without authentik / locally

i haven't found an actual fix for this yet, partly because i think it's related to the built-in caching of it-tools, since it can work without an internet connection for IT issues if you already accessed it before - which is great but somewhat conflicts with the nature of exposing it with authentik per se. my understanding could be right or wrong, but it also helped me find a workaround

the workaround

there was a potential workaround i found recently that works for me (without unauthenticated paths) which kinda sounds similar to @Loigzorn's workaround

• load your it-tools instance
• if text-diff / mac-address-lookup isn't working (you're in the "expired auth cached state")
• hard reload the page (ctrl+shift+r / cmd+shift+r).
• you should be presented with the authentik login page
• authenticate - then after authentikating you would be presented with the 404 screen. (but look at the URL now - it should have the authentik params still. so it looks like you're still in the cached state and it didn't fully forward the request to authentik because it just serves the cache. which also means it didn't fully re-authentikate/refresh the token)
• (crucial) hard reload again while on the 404 screen and the said tool/page should load and work again. (you need to hard reload with the valid authentik params still intact in the url to re-authentikate and reload the cache of the page)
• hard reloading again while on the 404 screen after re-authentikating was the key difference for me. because while on the 404 screen (after re-authentikating), the url still has the authentik params it needs to actually complete the authentikation process. otherwise, you'll have to log out of authentik and repeat the process to reestablish the params

not the best workaround but it's been a stable middle ground between getting it to work without changing the caching nature of IT-Tools, and securing it without unauthenticated paths. i don't use the text-diff tool super often so this workaround is fine for me for only when i need it.

i have a theory that you could also update the token validity to a longer period in the authentik proxy provider settings (IT-Tools instance only) to not have to do this work around as often but i haven't really had the need to test this thought yet

[gitmotion]

When I tested it, it showed me a 404 (because /assets/test does not exist) but completely bypassed the forward authentication via authentik. From this 404 screen you are able to use it-tools freely, as long as you don't refresh the page.

this actually sounds more like the built-in caching at play. but yeah rather not set the unauthenticated paths if possible