🚀 Feature: Mark certain apps so they do not appear in "my apps" for any user #424

Open
opened 2026-02-04 19:39:42 +03:00 by OVERLORD · 8 comments
Owner

Originally created by @nathanapples on GitHub (Aug 18, 2025).

Feature description

checkbox on the page for adding an oidc client for making the app appear or not appear on the "my apps page"

Pitch

Some oidc clients are not strictly speaking apps that you would have any desire to "go to" or display in that list. For example I have cloudflare as an oidc client so that I can use cloudflare access rules for certain sites. Cloudflare access itself is not an "app", you cannot go to it in the way you can other apps, and I would like to not confuse users who have the ability to authenticate with cloudflare that there is an app named cloudflare.

Originally created by @nathanapples on GitHub (Aug 18, 2025). ### Feature description checkbox on the page for adding an oidc client for making the app appear or not appear on the "my apps page" ### Pitch Some oidc clients are not strictly speaking apps that you would have any desire to "go to" or display in that list. For example I have cloudflare as an oidc client so that I can use cloudflare access rules for certain sites. Cloudflare access itself is not an "app", you cannot go to it in the way you can other apps, and I would like to not confuse users who have the ability to authenticate with cloudflare that there is an app named cloudflare.
OVERLORD added the needs more upvotes label 2026-02-04 19:39:42 +03:00
Author
Owner

@kmendell commented on GitHub (Aug 18, 2025):

I suppose we could, just not show the app uf the launch url is blank? Would that be a suitable solution? @stonith404 whats your thoughts on that?

@kmendell commented on GitHub (Aug 18, 2025): I suppose we could, just not show the app uf the launch url is blank? Would that be a suitable solution? @stonith404 whats your thoughts on that?
Author
Owner

@stonith404 commented on GitHub (Aug 18, 2025):

I think this is a valid idea, but there’s a problem: the page is also used to revoke authorized clients. If we only showed clients with a launch URL, users wouldn’t be able to revoke access for clients that don’t have one.

@nathanapples Since users should be able to see all authorized clients and revoke access if needed, I think it still makes sense to display the client regardless. In that case I would just leave the launch URL empty. What do you think?

@stonith404 commented on GitHub (Aug 18, 2025): I think this is a valid idea, but there’s a problem: the page is also used to revoke authorized clients. If we only showed clients with a launch URL, users wouldn’t be able to revoke access for clients that don’t have one. @nathanapples Since users should be able to see all authorized clients and revoke access if needed, I think it still makes sense to display the client regardless. In that case I would just leave the launch URL empty. What do you think?
Author
Owner

@nathanapples commented on GitHub (Aug 19, 2025):

Apps only show up if you've authenticated and you are using this page as a way to manage which apps you would like to still have access to your credentials?

If so, I guess that makes sense to not take away a user's ability to manage access to some extent. I mean ultimately this is in my homelab where I have friends and family who are using pocket to access certain apps. I am kind of using this page as a launch spot for applications. I think the cloudflare auth being in their "apps" list is more confusing than helpful in my use case but I totally get where you are coming from because I am probably in the minority.

Proposed compromises:

1 - What about at least being able to add a description to each app so users can be explained what the auth is for and why there might be a greyed link or whatever?

Image

2 - Another suggestion is to have it broken into sections where you can customize what the title of the section is like "my apps" could be one section and "authentication service" or something could be another category.

Image

Another idea now that I understand the function of the "my apps" page better:

1 - I would like to be able to "turn on" apps in this "my apps" section that you have not authenticated with yet as a way to get to apps in my community of apps that you are allowed to authenticate with. This could be in another section called "not yet authenticated" or have some kind of indication that you are not yet using it. Also whether the app displays could be based on whether the user is in an "allowed group" for the user. Let me know if I should create a separate feature suggestion for this.

@nathanapples commented on GitHub (Aug 19, 2025): Apps only show up if you've authenticated and you are using this page as a way to manage which apps you would like to still have access to your credentials? If so, I guess that makes sense to not take away a user's ability to manage access to some extent. I mean ultimately this is in my homelab where I have friends and family who are using pocket to access certain apps. I am kind of using this page as a launch spot for applications. I think the cloudflare auth being in their "apps" list is more confusing than helpful in my use case but I totally get where you are coming from because I am probably in the minority. Proposed compromises: 1 - What about at least being able to add a description to each app so users can be explained what the auth is for and why there might be a greyed link or whatever? <img width="1989" height="579" alt="Image" src="https://github.com/user-attachments/assets/fbb1685e-9d96-48fe-9790-90e54c6b5d0c" /> 2 - Another suggestion is to have it broken into sections where you can customize what the title of the section is like "my apps" could be one section and "authentication service" or something could be another category. <img width="1972" height="1141" alt="Image" src="https://github.com/user-attachments/assets/d1a3b4f5-cd9e-4317-9d2e-5e607a83954e" /> Another idea now that I understand the function of the "my apps" page better: 1 - I would like to be able to "turn on" apps in this "my apps" section that you have not authenticated with yet as a way to get to apps in my community of apps that you are allowed to authenticate with. This could be in another section called "not yet authenticated" or have some kind of indication that you are not yet using it. Also whether the app displays could be based on whether the user is in an "allowed group" for the user. Let me know if I should create a separate feature suggestion for this.
Author
Owner

@cweagans commented on GitHub (Dec 29, 2025):

Another use-case: I have local development versions of some apps. I never want them to appear on my app dashboard.

Current workaround: allow a local dev user group then toggle my user's membership in that group as needed. This is not a particularly good workaround, but it does keep my app dashboard tidy at least.

@cweagans commented on GitHub (Dec 29, 2025): Another use-case: I have local development versions of some apps. I never want them to appear on my app dashboard. Current workaround: allow a local dev user group then toggle my user's membership in that group as needed. This is not a particularly good workaround, but it does keep my app dashboard tidy at least.
Author
Owner

@sweepies commented on GitHub (Jan 15, 2026):

@kmendell Could we revisit this? Looks like a good number of folks are in support.

@sweepies commented on GitHub (Jan 15, 2026): @kmendell Could we revisit this? Looks like a good number of folks are in support.
Author
Owner

@kmendell commented on GitHub (Jan 15, 2026):

The apps dashboard was never meant to be a alternative to things like authentiks dashboard for example, it mainly was a simple way to add display of apps, and like @stonith404 said this is also used to revoke authorizations. Add customizable options to each client would just add extra bulk to the UI and we strive to keep pocket id simple and minimal indesign.

IF the launch url is left blank the button will be disabled.

Elias is away currently but ill see if i can implement something simple for categories, but only if its not adding a ton of bulk to the UI.

@kmendell commented on GitHub (Jan 15, 2026): The apps dashboard was never meant to be a alternative to things like authentiks dashboard for example, it mainly was a simple way to add display of apps, and like @stonith404 said this is also used to revoke authorizations. Add customizable options to each client would just add extra bulk to the UI and we strive to keep pocket id simple and minimal indesign. IF the launch url is left blank the button will be disabled. Elias is away currently but ill see if i can implement something simple for categories, but only if its not adding a ton of bulk to the UI.
Author
Owner

@sweepies commented on GitHub (Jan 15, 2026):

The way I see it, the simplicity benefit of Pocket ID comes mainly from:

  • More modern programming principles / language
  • Lack of complex flow/stage configuration
  • Single auth method

I do not believe this change / category of feature compromises on Pocket ID's simplicity. No one is passing up Pocket ID because you can customize the Apps page. I'd push back rather strongly on that viewpoint.

In fact, if this is determined to be out of scope, most everyone will have to just set up another dashboard / apps page to show what they want. This increases overall setup complexity.

@sweepies commented on GitHub (Jan 15, 2026): The way I see it, the simplicity benefit of Pocket ID comes mainly from: - More modern programming principles / language - Lack of complex flow/stage configuration - Single auth method I do not believe this change / category of feature compromises on Pocket ID's simplicity. No one is passing up Pocket ID because you can customize the Apps page. I'd push back rather strongly on that viewpoint. In fact, if this is determined to be out of scope, most everyone will have to just set up another dashboard / apps page to show what they want. This *increases* overall setup complexity.
Author
Owner

@nathanapples commented on GitHub (Jan 18, 2026):

At the min I think visibility of apps should at least be tie-able to user group or permissions rather than being strictly tied to what you have previously authenticated with. Just my opinion. Totally get it if it's out of scope. No big deal.

@nathanapples commented on GitHub (Jan 18, 2026): At the min I think visibility of apps should at least be tie-able to user group or permissions rather than being strictly tied to what you have previously authenticated with. Just my opinion. Totally get it if it's out of scope. No big deal.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id#424