Make all profile public
Merge request reports
Activity
Reassigned to @vsizov
Added 1 commit:
- ff30b407 - Make all profile public
@dzaporozhets please review
@vsizov what about group profiles? Groups and users share same username scope. If I can access
gitlab.com/valery
I should also be able to accessgitlab.com/rails
@dzaporozhets I think group profiles shouldn't always be public.
You don't want to leak the existence of a private group through the profile page.@haynes in this case it is half-solution which is confusing to me.
- Why my user page is public but group page is private?
- What should I do to make my group page public?
- When I sign-up with username
foo
- system says it is taken. But when I go togitlab.com/foo
it says 404.
@dzaporozhets I get your point.
But i'm absolutly against making all private groups public.
This can leak information about private projects. Especially if the group has a description.A public user profile doesn't leak any sensitive information So I think making those all public is fine.
What should I do to make my group page public?
As soon as the group contains a public project, the group becomes public.
If it only contains private projects we shouldn't make it public.
Also you normally won't accessgitlab.com/foo
if it's a private group because you don't know it exists.When I sign-up with username foo - system says it is taken. But when I go to gitlab.com/foo it says 404.
If there is already a way to find out if a group exists, maybe a solution would be to display a page that says
this page is private
instead of404
When I sign-up with username foo - system says it is taken. But when I go to gitlab.com/foo it says 404.
What is the problem with this behavior @dzaporozhets ?
@sytses What is your opinion?
What is the problem with this behavior
@jacobvosmaer inconsistency. Groups and Users share same username scope but treated differently
@haynes you know username is taken but
gitlab.com/foo
gives you 404 - you already know its group. Since group username is almost group name it makes no sense to hide group name behind 404.What we have on group page:
- username
- name
- description
- avatar
Basically we would know first 2 even if we make group page private. I dont think avatar is something to hide. Description - maybe.
Edited by Dmytro Zaporozhets (DZ)@dzaporozhets I don't buy that argument. You say that by trying to change your username, or by creating a new user you can probe for namespace paths that are taken. That requires a user account on the gitlab server, and it requires probing. That is not the same as looking at the profile of a user and seeing a complete list of all groups they belong to, with details beyond the path of the group. It is like the difference of trying random phone numbers versus getting a list of contacts from somebody's address book.
That is not the same as looking at the profile of a user and seeing a complete list of all groups they belong to
@jacobvosmaer in case we misunderstood each other I am talking not about rendering member ship or anything but about
gitlab.com/:groupname
being public page even with just a username and avatar.What we have on group page:
username name description avatar
Basically we would know first 2 even if we make group page private. I dont think avatar is something to hide. Description - maybe.
Also group members.
I think the description and the group members should not be public for private groups.
Avatar.... depends. Imagine you are are programming a sequel of a popular mobile game. The avatar can possibly leak this.That would leave us with:
- username
- groupname
I don't think we need a page that displays only those informations.
It doesn't give the user any relevant information.
I'm fine with replacing the 404 with a page that says it's a private group because you can already find it with probing.@haynes @jacobvosmaer Here is example from github - https://github.com/wow123456. It just shows avatar and organization name only. Still I find it more attractive than 404.
Edited by Dmytro Zaporozhets (DZ)@dzaporozhets what about a page like this? (better styled of course):
This page doesn't provide any information apart from the groupname that's in the url and can be found with probing anyway.
@haynes I think this is awesome
I am not sure if I can convince anyone but I think showing 404s is better, you can always put text on the 404 that explains that the URL might be correct but that you do not have access. (Don't we already have that?)
I think it is very strange to go from 'a user has no access to resource X' to 'I do not like how the 404 page looks' to 'a user should have access to resource X'.
@jacobvosmaer I'm fine with both. Keeping the 404 or displaying a site like the mockup i posted.
The mockup is a compromise between 'make the group profile public' and 'keep the 404'@haynes good point. Lets merge this one since our discussion should not block it
mentioned in commit 53698401
I think it is very strange to go from 'a user has no access to resource X' to 'I do not like how the 404 page looks' to 'a user should have access to resource X'.
@jacobvosmaer I am ok with how 404 looks. My concept is that if we agree on not hiding group names (since you can find them anyway) its easier to render group page like GitHub does (with minimal information) rather than confuse user with 404. cc @haynes
Edited by Dmytro Zaporozhets (DZ)In this case we can simplify other related things. For example we don't need to check permission to access group username in markdown comments. For example when we reference group like
hey @developers
we can just always render it as a link without checking if user will get 404 on this page or will see actual group page.Because right now every time we render a comment to user we check if group is mentioned in this comment and if user has access to this group to decide if we should render it as a link or as a plain text. Such kind of overhead can be avoided by simply making group page public even if there is nothing to show here except name.
@dzaporozhets I think it OK to have show a minimal page for private groups. Most companies with secret projects use code names anyway.
@sytses I agree with you. We will proceed in this direction
Thanks, mentioned in https://dev.gitlab.org/gitlab/gitlabhq/issues/1361#note_56141
mentioned in issue #2973 (closed)
mentioned in commit stanhu/gitlab-ce@b35d5a6a
mentioned in commit ben.boeckel/gitlab-ce@b35d5a6a
mentioned in commit stevenorman/gitlab-ce@b35d5a6a
mentioned in commit pravi/gitlab-ce@b35d5a6a
mentioned in commit fengweijie/gitlab-ce@b35d5a6a
mentioned in commit axil/gitlab-ce@b35d5a6a
mentioned in commit mrts/gitlab-ce@b35d5a6a
mentioned in commit dmitrych61/gitlab-ce@b35d5a6a
mentioned in commit bugagazavr/gitlab-ce@b35d5a6a
mentioned in issue #12658 (closed)
mentioned in commit rickettm/gitlab-ce@b35d5a6a
mentioned in commit klowner/gitlab-ce@b35d5a6a
mentioned in commit jeroenj/gitlab-ce@b35d5a6a
Mentioned in commit pfjason/gitlab-ce@b35d5a6a