lix-project/hydra
4
2
Fork 9
Code Issues 4 Pull requests 3 Projects Releases Packages Wiki Activity

Don't show hidden projects on front page if user not logged in #65

Open
srd424 wants to merge 1 commit from srd424/hydra:hide-projects into main
pull from: srd424/hydra:hide-projects
merge into: lix-project:main
Conversation 2 Commits 1 Files changed 1 +7 -5
srd424 commented 2025-09-08 20:40:46 +00:00
First-time contributor
Copy link

This PR has been languishing on the upstream repo (as gh#1383) for a while, so I thought you folks might take it - feel free to close if not.

Maybe/partly fixes upstream bug gh#486. A blunt instrument and doesn't deal with all the cases, but then I don't get the impression hiding projects was intended as any sort of security feature. This just unclutters the front page a little, and obscures my embarrassing test projects to a degree :)

If one wanted to enhance this a bit, adding a "show hidden" toggle for logged in users would be the next obvious step.

This PR has been languishing on the upstream repo (as [gh#1383](https://github.com/NixOS/hydra/pull/1383)) for a while, so I thought you folks might take it - feel free to close if not. Maybe/partly fixes upstream bug [gh#486](https://github.com/NixOS/hydra/issues/486). A blunt instrument and doesn't deal with all the cases, but then I don't get the impression hiding projects was intended as any sort of security feature. This just unclutters the front page a little, and obscures my embarrassing test projects to a degree :) If one wanted to enhance this a bit, adding a "show hidden" toggle for logged in users would be the next obvious step.
ma27 reviewed 2025-09-17 19:42:07 +00:00
src/root/overview.tt Outdated
@ -61,0 +59,4 @@
<td>[% HTML.escape(p.displayname) %]</td>
<td>[% WRAPPER maybeLink uri=p.homepage %][% HTML.escape(p.description) %][% END %]</td>
</tr>
[% END %]
ma27 commented 2025-09-17 19:42:07 +00:00
Member
Copy link

I think this is the wrong approach? If you look at h.n.o, the hidden/visible toggle just works and doesn't show hidden projects by default? We just need to find out why.

I think this is the wrong approach? If you look at h.n.o, the hidden/visible toggle just works and doesn't show hidden projects by default? We just need to find out why.
srd424 commented 2025-09-17 19:48:51 +00:00
Author
First-time contributor
Copy link

Hmm, does h.n.o actually have any hidden projects that aren't also disabled? I don't have a login there so if it is working I can't tell!

I'll look at this again but obviously when I first made the patch I couldn't find any logic that seemed to implement this functionality. Upstream bug gh#486 long predates my nix time so obviously I'm not the only one to think it's broken at least in some deployments. Does h.n.o always run mainline code?

Hmm, does h.n.o actually have any hidden projects that aren't also disabled? I don't have a login there so if it is working I can't tell! I'll look at this again but obviously when I first made the patch I couldn't find any logic that seemed to implement this functionality. Upstream bug [gh#486](https://github.com/NixOS/hydra/issues/486) long predates my nix time so obviously I'm not the only one to think it's broken at least in some deployments. Does h.n.o always run mainline code?
ma27 commented 2025-09-17 20:02:08 +00:00
Member
Copy link

First of all, sorry I've been conflating a few things, I'll take that back! This was the result of me being confused about the behavior on my own instance where I forgot to disable a jobset, short of hiding it.

If you want slightly better private projects, I have 10571116d1.

Anyways, I think this is the correct behavior, even if that's not a security feature (i.e. disabling it). But then again, the entire feature is pretty weird. What do @vriska and @benaryorg think?

First of all, sorry I've been conflating a few things, I'll take that back! This was the result of me being confused about the behavior on my own instance where I forgot to disable a jobset, short of hiding it. If you want slightly better private projects, I have https://git.lix.systems/ma27/hydra/commit/10571116d10484033f7608463382241c254f4a3d. Anyways, I think this is the correct behavior, even if that's not a security feature (i.e. disabling it). But then again, the entire feature is pretty weird. What do @vriska and @benaryorg think?
benaryorg commented 2025-09-19 04:50:27 +00:00
Contributor
Copy link

IMHO

Enabled Visible in projects list result
✅ ✅ displayed normally
✅ ❌ not displayed
❌ ❌ not displayed
❌ ✅ displayed as disabled (greyed out, strikethrough, etc.)

On top of this the project view should get the same kind of UI toggles as are present in the jobset view (i.e. hide/show disabled with default show, hide/show hidden with default hide).
For users not logged in the list may be filtered server-side (not just hidden in the UI via CSS/JS), and the "hidden" button should be disabled.
Personally I'd advocate just disabling the button and leaving the HTML as-is to emphasize that this is not a security feature and to simplify the code (injecting "disabled" into the button rather than having to actually filter the list).

Any sort of "private" mechanic (i.e. only visible for logged in users) is orthogonal to this.
Effectively anything that requires authentication to be accessible at all would be filtered before the above criteria to begin with (i.e. in the DB query, ensuring they cannot accidentally slip through), and may be displayed slightly special, ideally something that "stacks" with the disabled effect such that no special handling for private and disabled needs to be implemented (e.g. disabled doing a strikethrough and grey text, and private changing the background colour slightly).

# IMHO |Enabled|Visible in projects list|result| |:--:|:--:|:---| |✅|✅|displayed normally| |✅|❌|not displayed| |❌|❌|not displayed| |❌|✅|displayed as disabled (greyed out, strikethrough, etc.)| On top of this the project view should get the same kind of UI toggles as are present in the jobset view (i.e. hide/show disabled with default show, hide/show hidden with default hide). For users not logged in the list may be filtered server-side (not just hidden in the UI via CSS/JS), and the "hidden" button should be disabled. Personally I'd advocate just disabling the button and leaving the HTML as-is to emphasize that this *is not a security feature* and to simplify the code (injecting "disabled" into the button rather than having to actually filter the list). Any sort of "private" mechanic (i.e. only visible for logged in users) is orthogonal to this. Effectively anything that requires authentication to be *accessible at all* would be filtered before the above criteria to begin with (i.e. in the DB query, ensuring they cannot accidentally slip through), and may be displayed slightly special, ideally something that "stacks" with the disabled effect such that no special handling for private *and* disabled needs to be implemented (e.g. disabled doing a strikethrough and grey text, and private changing the background colour slightly).
ma27 commented 2025-09-21 12:13:55 +00:00
Member
Copy link

So, the suggestion is to hide via JS and add a toggle, just like for the jobsets?

Works for me, some consistency in Hydra wouldn't hurt ;-)

So, the suggestion is to hide via JS and add a toggle, just like for the jobsets? Works for me, some consistency in Hydra wouldn't hurt ;-)
benaryorg commented 2025-09-23 01:21:20 +00:00
Contributor
Copy link

One thing that just came to mind; the JSON API.

As can be seen on my hydra, the API returns all projects regardless of hidden/enabled settings.
This indicates the h.n.o just doesn't have any projects that are hidden and enabled.

curl -sLH "accept: application/json" https://hydra.nixos.org | jq -c ".[] | {displayname,hidden,enabled}"

# or if you prefer tables
curl -sLH "accept: application/json" "https://hydra.nixos.org" | jq -r 'map({displayname,hidden,enabled}) | (first | keys_unsorted), (.[] | [.[]]) | @tsv' | column -ts $'\t'

This somewhat supports what I wrote earlier; I would prefer this to be a UI thing only.
Since the entire feature is not about security it makes sense to expose these things via the API (such as to build discovery rules for monitoring), and likewise include them in the HTML code (i.e. hitting Ctrl+U should tell you the same thing the API does).
Again: big IMHO; the templating should include the hidden projects regardless.
Whether or not the "show hidden" toggle can be used by anonymous users (i.e. whether the UI element is enabled/disabled for users without a session) can be a config option.
That way people can decide whether to expose their hidden projects, or hide them behind a superficial barrier.

Again this does play nicely with any "private" project features as mentioned by others, since those features would merely adjust the DB query of sorts, and thus leave the templating untouched.
The same logic regarding visibility in the UI/API would apply, except that project which are actually private would never show without authentication, and with authentication would behave exactly the same as without the privacy feature (± some styling).
This'd apply to both UI and API alike.

One thing that just came to mind; the JSON API. As can be seen on [my hydra](https://hydra.cloud.bsocat.net), the API returns all projects regardless of hidden/enabled settings. This indicates the [h.n.o](https://hydra.nixos.org) just doesn't have any projects that are hidden and enabled. ```bash curl -sLH "accept: application/json" https://hydra.nixos.org | jq -c ".[] | {displayname,hidden,enabled}" # or if you prefer tables curl -sLH "accept: application/json" "https://hydra.nixos.org" | jq -r 'map({displayname,hidden,enabled}) | (first | keys_unsorted), (.[] | [.[]]) | @tsv' | column -ts $'\t' ``` This somewhat supports what I wrote earlier; I would prefer this to be a UI thing only. Since the entire feature is not about security it makes sense to expose these things via the API (such as to build discovery rules for monitoring), and likewise include them in the HTML code (i.e. hitting Ctrl+U should tell you the same thing the API does). Again: **big IMHO**; the templating should include the hidden projects regardless. Whether or not the "show hidden" toggle can be used by anonymous users (i.e. whether the UI element is enabled/disabled for users without a session) can be a config option. That way people can decide whether to expose their hidden projects, or hide them behind a superficial barrier. Again this does play nicely with any "private" project features as mentioned by others, since those features would merely adjust the DB query of sorts, and thus leave the templating untouched. The same logic regarding visibility in the UI/API would apply, except that project which are actually private would *never* show without authentication, and with authentication would behave exactly the same as without the privacy feature (± some styling). This'd apply to both UI and API alike.
ma27 commented 2025-10-03 19:26:22 +00:00
Member
Copy link

@srd424 would you be motivated to extend the functionality of the JS code as described above? :))

@srd424 would you be motivated to extend the functionality of the JS code as described above? :))
srd424 commented 2025-10-03 19:38:28 +00:00
Author
First-time contributor
Copy link

Ah, realistically I'm likely lacking in both time and expertise on that front! Do feel free to close this PR off it's not the preferred resolution

Ah, realistically I'm likely lacking in both time and expertise on that front! Do feel free to close this PR off it's not the preferred resolution
srd424 commented 2025-09-17 20:11:26 +00:00
Author
First-time contributor
Copy link

Ooh, that looks nice! But yeah, I wasn't even aiming for security here, just "tidy" (and maybe not embarrassing myself by exposing hacky test projects.) Hiding could probably be done via CSS somehow, but honestly, I suspect doing it this way in the template is going to be cleaner.

Ooh, that looks nice! But yeah, I wasn't even aiming for security here, just "tidy" (and maybe not embarrassing myself by exposing hacky test projects.) Hiding could probably be done via CSS somehow, but honestly, I suspect doing it this way in the template is going to be cleaner.
👍 1
srd424 force-pushed hide-projects from 3b10cf3ddc to ef8d100c03 2025-09-18 20:22:11 +00:00 Compare
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u hide-projects:srd424-hide-projects
git switch srd424-hide-projects

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff srd424-hide-projects
git switch srd424-hide-projects
git rebase main
git switch main
git merge --ff-only srd424-hide-projects
git switch srd424-hide-projects
git rebase main
git switch main
git merge --no-ff srd424-hide-projects
git switch main
git merge --squash srd424-hide-projects
git switch main
git merge --ff-only srd424-hide-projects
git switch main
git merge srd424-hide-projects
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/hydra#65
No description provided.
Delete branch "srd424/hydra:hide-projects"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?