[Feature Request] Identity based visibility

[discretizer]

Description

There have been many requests for this feature in various guises, but I believe to core feature is the ability to configure component visibility (links, widgets, groups, etc...) based on some form of user identification that's presented to the application. I totally agree that user authentication is BEYOND the scope of what homepage should be trying to do, but accepting forms of user identification (such as proxy headers or JWTs) and changing the appearance of the application is potentially IN scope.

I currently have a fork that implements this feature for proxy authentication here:

https://github.com/discretizer/homepage

The relevant documentation for the proof of concept is here:

There is certainly a larger discussion to be had on if there should be ANY identity based customization and how much identity based customization should be allowed.

Other

Similar feature requests:

• [Feature Request] Widgets (etc) showing based on SSO groups #3782

[polarathene]

Just so I understand the current situation with homepage (I haven't tried deploying it yet):

• Presently you would need to create individual instances, presumably incurring much more overhead to serve each individual unique user/group dashboard?
• The service discovery in docker / k8s via annotations does support filtering by homepage instance for visibility.

So each unique homepage instance would then add a new annotation and another container. While an auth service would sit in front, login and need to route to the correct instance?

---

Using config with some customization for header to get this info seems like the way to minimize the friction for homepage being able to properly support such a popular use-case request. You've documented that (just so others can reference it), which shouldn't affect the original PR concerns raised as any LDAP/OIDC or other auth solution can remain external of homepage, but to get the desired functionality it does seem like homepage needs to at least support configuring visibility?

You'd probably need the value given to be something with more entropy that can map to a friendly group name though. Otherwise anyone who has been authenticated could do a request that enumerates groups for example and adjust the visibility to see groups they're not actually permitted to. Although I suppose that could still be abstracted out too, and some users may not care about that concern either way, just this bare minimum visibility functionality 🤔

[discretizer]

You'd probably need the value given to be something with more entropy that can map to a friendly group name though. Otherwise anyone who has been authenticated could do a request that enumerates groups for example and adjust the visibility to see groups they're not actually permitted to.

@polarathene I think generally most authenticating proxies implement client header whitelists for non-standard headers so this seems like it would prevent any spoofing.

I think the bigger issue with my solution is that this it makes most of the response data un-cacheable. While the recommended solution gets around this, there might be a workable 'middle' ground where users who want this feature will get cached data. I'm not a Typescript/JS guru, so someone who's more familiar with the underlying frameworks might be able to work through a better solution.

[contagon]

Hey @discretizer, this is awesome work! I could use some help getting it working if you don't mind. I'm currently trying to use it with Authelia/Caddy - I've setup Caddy to forward the Authelia headers "Remote-User" and "Remote-Groups". Here's my corresponding homepage setting,

identity:
  provider:
    type: proxy
    groupHeader: "Remote-Groups"
    userHeader: "Remote-User"

And I'm running your most recent docker release. Unfortunately, when navigating to homepage, I get a black page saying "Application error: a client-side exception has occurred (see the browser console for more information)." In the console I see a number of TypeError: Cannot read properties of null (reading 'classList') and in the homepage logs error:undefined

Any ideas? (note, I also get this same behavior without the "identity" section in the yaml, and when just navigating via IP:3000)

[discretizer]

Looking into this this morning. Will update when I've got a solution.