project visibility (disabled vs. hidden)

benaryorg commented

2025-05-24 00:15:07 +00:00

Contributor

For the first time in forever I'm actually double checking with a private window of my browser and the way the project list handles visibility seems counter intuitive and I'm wondering whether something's using the wrong flag there.

When looking at a project with disabled&hidden jobsets (read: "deleted" ones) I can only see them when logged in, and when enabling both "Show disabled jobsets" and "Show hidden jobsets".
When not logged in, then the "Show hidden jobsets" toggle is simply gone so I can't see them even if "disabled" jobsets are displayed (presumably).

However when looking at the project list I have the same "Show disabled projects" toggle, however the one project which has the "Visible in projects list" setting set to false (the project is "Enabled" though) is visible regardless as a greyed out item.

My gut tells me that in the project list, as an anonymous user I should be able to not see a project which is "Enabled" but not "Visible in projects list".
Since this is my gut speaking though, I'd like a second opinion on this ^^

TL;DR: is the below behaviour the desired behaviour for anonymous (not logged in) users?

For the first time in forever I'm actually double checking with a private window of my browser and the way the project list handles visibility seems counter intuitive and I'm wondering whether something's using the wrong flag there. When looking at a project with disabled&hidden jobsets (read: "deleted" ones) I can only see them when logged in, and when enabling both "Show disabled jobsets" and "Show hidden jobsets". When not logged in, then the "Show hidden jobsets" toggle is simply gone so I can't see them even if "disabled" jobsets are displayed (presumably). However when looking at the project list I have the same "Show disabled projects" toggle, however the one project which has the "Visible in projects list" setting set to *false* (the project is "Enabled" though) is visible regardless as a greyed out item. My gut tells me that in the project list, as an anonymous user I should be able to not see a project which is "Enabled" but not "Visible in projects list". Since this is my gut speaking though, I'd like a second opinion on this ^^ --- TL;DR: is the below behaviour the desired behaviour for anonymous (not logged in) users? ![screenshot of the settings of a "testing" project, set to Enabled, but not Visible in projects list](/attachments/c322cae8-1860-424e-a856-022dccf61d25) ![screenshot of the project list, showing the greyed out "testing" project](/attachments/94794d3f-5e62-472f-a946-9309fd04d140)

image.png

30 KiB

image.png

10 KiB

ma27 commented

2025-05-24 13:04:59 +00:00

Member

Is what you're looking for a security feature or a way to hide obsolete stuff?

For the latter: IIRC the only reason why delete got disabled in the UI is that it's currently far too expensive (i.e. it cascades deletion to builds etc.).

Regarding visibility: I never really understood this feature considering that there's no access control anyways and build numbers are easily guessable (how many information leaks did we have because somebody incremented an ID in a URL?).

So, maybe the visibility part is something to kill?

My ideas are:

implement deletion in a more reasonable way (e.g. by marking a jobset as deleted and deleting stuff in the background or maybe even reconfigure the schema to only create the jobset?)
remove the visibility entirely for something more reasonable regarding access control. For instance, I'm carrying around 5bb556bdc6 for quite a while now.

Be careful with applying though, I removed the database migration at one point because I got tired at rebasing against Hydra changes including other migrations. Technically, there's still an information disclosure since it gives you a 403 for private stuff (vs. 404 for non-existing stuff) and I'm telling myself for a few years that I'll eventually fix it, but for now it's good enough.

Thoughts?

Is what you're looking for a security feature or a way to hide obsolete stuff? For the latter: IIRC the only reason why delete got disabled in the UI is that it's currently far too expensive (i.e. it cascades deletion to builds etc.). Regarding visibility: I never really understood this feature considering that there's no access control anyways and build numbers are easily guessable (how many information leaks did we have because somebody incremented an ID in a URL?). So, maybe the visibility part is something to kill? My ideas are: * implement deletion in a more reasonable way (e.g. by marking a jobset as deleted and deleting stuff in the background or maybe even reconfigure the schema to only create the jobset?) * remove the visibility entirely for something more reasonable regarding access control. For instance, I'm carrying around https://git.lix.systems/ma27/hydra/commit/5bb556bdc625a17f5eb18723dbd761efe0028f41 for quite a while now. Be careful with applying though, I removed the database migration at one point because I got tired at rebasing against Hydra changes including other migrations. Technically, there's still an information disclosure since it gives you a 403 for private stuff (vs. 404 for non-existing stuff) and I'm telling myself for a few years that I'll eventually fix it, but for now it's good enough. Thoughts?

benaryorg commented

2025-05-25 03:18:29 +00:00

Author

Contributor

Is what you're looking for a security feature or a way to hide obsolete stuff?

More of a "hide irrelevant stuff" thing (but it does extend to obsolete stuff too, I just haven't had that yet).
I don't want to advertise front and center my testing project for when I mess around with jobsets, or the temporary projects I use when I have to change my main project's jobset generation ("third force push on main while the primary projects is disabled").

It is good to know about 5bb556bdc6 though, thanks for linking that, though I really like working in the open so I won't need or use that anytime soon.

For the latter: IIRC the only reason why delete got disabled in the UI is that it's currently far too expensive (i.e. it cascades deletion to builds etc.).

AFAIK that only applies to jobsets though, deleting a projects in its entirety works fine (I think), including the cascading deletes.
So on the project level the hidden/disable switches are literally just that; "hide in project list" and "do not actually run this right now".

So, maybe the visibility part is something to kill?

Continuing the previous section; And having the option to basically keep the project list clean for anonymous users is a feature I get (and would like to use), personally.
Just a means of hiding some of the less useful stuff.
Think of an image building project which just builds a bunch of images (ISO, etc.) for various platforms; it's something I'd use myself, something I might want to link to, but not necessarily something that I'd want to clutter up the project list with.

> Is what you're looking for a security feature or a way to hide obsolete stuff? More of a "hide irrelevant stuff" thing (but it does extend to obsolete stuff too, I just haven't had that yet). I don't want to advertise front and center my testing project for when I mess around with jobsets, or the temporary projects I use when I have to change my main project's jobset generation ("third force push on main while the primary projects is disabled"). It is good to know about 5bb556bdc6 though, thanks for linking that, though I really like working in the open so I won't need or use that anytime soon. > For the latter: IIRC the only reason why delete got disabled in the UI is that it's currently far too expensive (i.e. it cascades deletion to builds etc.). **AFAIK** that only applies to jobsets though, deleting a projects in its entirety works fine (I think), including the cascading deletes. So on the project level the hidden/disable switches are literally just that; "hide in project list" and "do not actually run this right now". > So, maybe the visibility part is something to kill? Continuing the previous section; And having the option to basically keep the project list clean for anonymous users is a feature I get (and would like to use), personally. Just a means of hiding some of the less useful stuff. Think of an image building project which just builds a bunch of images (ISO, etc.) for various platforms; it's something I'd use myself, something I might want to link to, but not necessarily something that I'd want to clutter up the project list with.

ma27 commented

2025-06-10 19:26:35 +00:00

Member

I don't want to advertise front and center my testing project for when I mess around with jobsets, or the temporary projects I use when I have to change my main project's jobset generation ("third force push on main while the primary projects is disabled").

Sounds reasonable to me. I came exactly from the "trying to use as security feature"-usecase that I heard too often in the past.

I just realized that I also have a disabled project on my server and given that the "Show disabled projects" button is doing literally nothing, I'm pretty sure that it just got broken at some p[oint and nobody noticed (the git history of src/root/overview.tt also seems to confirm that).

So I guess it makes sense to fix this to have those rows hidden by default. If the button should be showed to anonymous users is something I don't care much about, as long as it's consistent with the jobset eval view.

Would you be interested in making such a change? I may get to it at some point as well, perhaps.

AFAIK that only applies to jobsets though, deleting a projects in its entirety works fine (I think), including the cascading deletes.

TIL.
Apparently somebody just forgot about this given that people only ever reported problems about jobset deletion being broken ;)

> I don't want to advertise front and center my testing project for when I mess around with jobsets, or the temporary projects I use when I have to change my main project's jobset generation ("third force push on main while the primary projects is disabled"). Sounds reasonable to me. I came exactly from the "trying to use as security feature"-usecase that I heard too often in the past. I just realized that I also have a disabled project on my server and given that the "Show disabled projects" button is doing literally nothing, I'm pretty sure that it just got broken at some p[oint and nobody noticed (the git history of `src/root/overview.tt` also seems to confirm that). So I guess it makes sense to fix this to have those rows hidden by default. If the button should be showed to anonymous users is something I don't care much about, as long as it's consistent with the jobset eval view. Would you be interested in making such a change? I may get to it at some point as well, perhaps. > AFAIK that only applies to jobsets though, deleting a projects in its entirety works fine (I think), including the cascading deletes. TIL. Apparently somebody just forgot about this given that people only ever reported problems about jobset deletion being broken ;)

Rows
Columns

project visibility (disabled vs. hidden) #44