Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enable Pages access control

gitlab.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Enable Pages access control

#31

Post by aaxa »

darau1 wrote: post #18
dewey wrote: post #17

Earlier quoted context omitted.

> My company has maybe 20-30 projects Ever worked in a company with micro services or a company that has a bunch of employees? You'll have hundreds of projects easily if it's a bunch of teams. If someone tells me "it's in our SRE libs package" I'll go ahead and search that. (Usually I can't find it because it's in a separate namespace on our Gitlab instance. Doing that is an Enterprise only feature on Gitlab right no…

I hadn't considered companies that use microservices instead of monoliths, I think you might be right

Actually, it doesn't even have to be microservices. At my current workplace we have over 1000 projects in our Gitlab. And many of those projects are a collection of up to 20 libraries.

Re: Enable Pages access control

#32

Post by [deleted] »

Skunkleton wrote: post #22
y4mi wrote: post #6

Earlier quoted context omitted.

That sounds like a great idea but quickly gets you into very murky Waters, especially wrt China. If the government in question doesn't try to be just, you'll end up assisting murder and silencing the voices of the oppressed. Sometimes it really is better to say "no" to a business opportunity, if the other side isn't behaving in a sane manner. And fwiw: gitlab did just that as the sister comment pointed out

I think this is more nuanced. Right now companies cooperation with China is in the news. For example, both Blizzard and the NBA have betrayed American ideals in favor of making money in China. Other companies have built a dependent relationship with China over many years, and have been forced through this dependence to support China (Apple comes to mind here). Other companies are actively distancing themselves from p…

[deleted]

Re: Enable Pages access control

#33

Post by lettergram »

darau1 wrote: post #16
dewey wrote: post #12

Earlier quoted context omitted.

This also affects self hosted instances in a company where you want to find other packages though. It's not a "social network" feature.

You're telling me there are cases where a company has so many projects in it's gitlab instance that employees routinely have to search for things? That seems odd to me. I'd expect there to be a naming scheme for most things, and even if there's some oddball project, I'd think somebody else you work with knows about it and where it is. My company has maybe 20-30 projects, and I can find any of them easily if I know th…

My team had 20-30 “projects” aka micro services / little libraries and demo repositories.

There are, idk, 2000 to 5000 teams at the company I work at.

Re: Enable Pages access control

#34

Post by StavrosK »

Can someone explain to me what this does? It seems to me that it restricts Pages to project members, but I've had that feature enabled on private repos for at least a week or two now, which makes me think this is something different, but I can't figure out what.

Re: Enable Pages access control

#35

Post by jfowl »

I really like their checklist. It brought many details to my attention that I would have missed when developing such a feature. Does anyone know such a list of checklist (awesome-checklists or so)?

Re: Enable Pages access control

#36

Post by hddqsb »

StavrosK wrote: post #34

Can someone explain to me what this does? It seems to me that it restricts Pages to project members, but I've had that feature enabled on private repos for at least a week or two now, which makes me think this is something different, but I can't figure out what.

That's what it does. It's not that new, it's been live since Sept 27 (https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues...).

Re: Enable Pages access control

#37

Post by StavrosK »

hddqsb wrote: post #36
StavrosK wrote: post #34

Can someone explain to me what this does? It seems to me that it restricts Pages to project members, but I've had that feature enabled on private repos for at least a week or two now, which makes me think this is something different, but I can't figure out what.

That's what it does. It's not that new, it's been live since Sept 27 ( https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues... ).

Ah, okay, that makes sense, thanks! I can't tell you how much trouble I've had deploying docs with authentication to an org that uses GitHub, I basically spent a whole day figuring something out and gave up. GitLab was literally one setting.

Re: Enable Pages access control

#38

Post by hddqsb »

I love GitLab, and Pages access control is a great feature, but I think this was rolled out very poorly.

The access level is "Only Project Members" by default for private projects, which I consider a breaking change because the steps I previously used to create public Pages (add .gitlab-ci.yml and push) no longer work.

The first time I tried to deploy Pages after the access control feature was enabled I wasted a lot of time because of this. When my new webpage redirect to the GitLab sign in page, I didn't bother signing in (why should I, when Pages have always been public?). I waited a day, because Pages have taken several hours to provision in the past[1]. Finally I started searching the web for why Pages was redirecting to the sign in page and found out about the access control feature.

I support having the access level "Only Project Members" by default, but I think the rollout could have been done much better. My main objections:

- There was no indication that the new webpage existed and that the issue was access control -- when I tried visiting the webpage for a non-existent project I got the same redirect. I understand why (to avoid leaking the names of private projects), but the redirected sign in page could have still shown a generic message ("project is missing or private") and mentioned that Pages are now private by default.

- The setting was not in an obvious location for me. I checked "Settings > Pages", which said the pages are served but did not give any indication that access control was enabled. There should have been a notice here saying that Pages are now private by default and that this can be changed in "Settings > General > Permissions", at least for the first few months after the rollout.

- The API [2] does not support changing the Pages access level yet, so I have to sign in to GitLab and change it manually (or fake the form submission). I want to be able to create a project with public Pages from the terminal, like I could before.

These issues could have stemmed from an assumption that developers heavily use the GitLab web interface and are always signed in. For me that is not the case.

Some small additional issues:

- The option "Pages access control" in Settings > General > Permissions is badly named because it's not clear what it means when it's toggled off. With the other options (e.g. "Issues", "Wiki", "Snippets") it's clear that toggling off the option removes the feature, but toggling off "Pages access control" could either mean "remove the access control feature" (making the pages available to everyone) or "remove the Pages feature" (making the pages available to no one). From my experiments it appears to be the second.

- The options have a glitch where toggling an option puts the corresponding access level in an inconsistent state. When the "Page access control" option of a private project is toggled off then on, the access level dropdown shows "Only Project Members" as selected but the value of the hidden element is 30 (Everyone). Submitting the form sets the access level to "Everyone", as can be seen when the page refreshes. The other options have the same problem.

[1] https://forum.gitlab.com/t/gitlab-pages-404-for-even-the-sim...

[2] https://docs.gitlab.com/ee/api/projects.html#edit-project

Re: Enable Pages access control

#39

Post by sytse »

hddqsb wrote: post #38

I love GitLab, and Pages access control is a great feature, but I think this was rolled out very poorly. The access level is "Only Project Members" by default for private projects, which I consider a breaking change because the steps I previously used to create public Pages (add .gitlab-ci.yml and push) no longer work. The first time I tried to deploy Pages after the access control feature was enabled I wasted a lot…

Thanks for the list. I've shared this with the group responsible for pages.
Post reply on HN