Security for non-logged-in users when reverse proxied

[mgrimace]

Hi,

I have Ocular reverse proxied to budget.mydomain.com - it looks like by default, even non-logged-in users can interact with the app (e.g., load demo data, import config.json, etc.), even if they can't save their own data. If it's exposed to the internet, is there a way to have zero interaction possible until a user logs in?

Alternatively, is there support for Authentik or Authelia?

[simonwep]

Heey :)

I feel like I should first give some context for why this app is build the way it is. Initially I first just wanted to set up a quick PWA with partial file system access (possible via Web APIs) to manage this - as I quickly realized I needed the data available in more than one place so I set it up as an web app where you can log in via google and sync your data to google-drive (see the legacy branch).

After a while I realized, that making this an official app that google would let users log into would take much more time than I anticipated. So I dumped that idea (since I have a full-time job and not that much time available) and decided to develop genesis that is a generic json api including very, very simple user and data-management that can basically run on a potato, hoping I could re-use it in other projects.

As you can see, everything from the UI down to the backend is kept as simple as possible to allow me to add features / work on it with minimal effort to make the most of the time available to me.

This is also the reason logging in and saving your data is a feature, rather than a necessity like it is for other self-hosted apps. Same goes for why I didn't go for KeyCloak (is this still a thing? I believe it was back then 😅), Authentik, Authelia or any other centrally managed auth provider.

But to answer your qustions:

1. Forbidding the user to load demo data / do anything - Currently not possible due to the simple reason the app is shipped pre-build. But I can think of ways doing that by dynamically generating a config file on deploy and importing that in the frontend afterwards. If you create a ticket for that I'll see what I can do :)
2. Using a centralized auth provider - That unfortunately is not planned, but who knows how many would profit from that and maybe I'm interested in it at some point. You can also create a ticket for that, but I wouldn't prioritize it as of right now.

[mgrimace]

That makes perfect sense, it seemed unusual to me at first glance, and I can appreciate having limited time/energy to devote to anything more complex. As it is, Ocular is exactly what I was looking for as a service, and I appreciate what you’ve done here.

What I ended up doing was just using Authentik in front as my ‘security’/centralized login. I can’t imagine it’d be worth your time to re-invent that functionality when something like Authelia/Authentik/KeyCloak(?) could already do the same thing anyways.

My best-case scenario is that Authentik/etc could (eventually) pass the login information through to Ocular by allowing proxy authentication via headers (e.g., X-authentik-username) in order to automatically log the same user and avoid the double log in. I’m not skilled or knowledgeable enough to contribute this work myself unfortunately.

I could add this as a [Feature Request] if it’s helpful to track, but for what it’s worth I don’t expect any action if it’s not a priority.

[simonwep]

I see, I'm glad others can make some use of it either way :) In this case I'd probably keep it as is, but you can create a ticket for limiting the UI actions down to the login if you want as this should be fairly easy to add. I can see this making sense if it's personal and not, as in my case, used as a show case as well ^^