-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ui.explore settings to control view of explore pages (2) #14094
Add ui.explore settings to control view of explore pages (2) #14094
Conversation
Add `[ui.explore]` settings to allow restricting the explore pages to logged in users only and to restrict the showing of users to only those with publically available repositories. The two proposed settings are: - `REQUIRE_SIGNIN_VIEW`: Only allows access to the explore pages if the user is signed in. Also restricts `/api/v1/user/search`. - `ONLY_SHOW_USERS_WITH_PUBLIC_REPOS`: Only shows users with public repos on the explore page. `/api/v1/user/search` will only show users with public repos unless the user the is signed in. Fix go-gitea#2908 Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: a1012112796 <[email protected]>
chinese translation
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #14094 +/- ##
=========================================
Coverage ? 42.33%
=========================================
Files ? 726
Lines ? 77756
Branches ? 0
=========================================
Hits ? 32918
Misses ? 39431
Partials ? 5407
Continue to review full report at Codecov.
|
Is there a use case where |
@lafriks |
imho we should remove users page completely, I don't see much use for it to be honest |
Maybe for a public big site, users want to find some people they want to contact. |
Please resolve the conflicts |
…plore-page-settings
Conflicts fixed. |
modules/setting/setting.go
Outdated
@@ -265,6 +270,10 @@ var ( | |||
Description: "Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go", | |||
Keywords: "go,git,self-hosted,gitea", | |||
}, | |||
Explore: struct { | |||
RequireSigninView bool `ini:"REQUIRE_SIGNIN_VIEW"` | |||
DisableUsersPage bool `ini:"DISABLE_USERS_PAGE"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think maybe move this to service is better? We need a feature to disable all the user explore include APIs. A standalone setting for UI search seems not enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really think we have way too much stuff in [service]
already - so if it's going in there it should go in [service.explore]
I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on [service.explore]
You are checking for the curl -X GET "http://gitea/api/v1/users/joe" -H "accept: application/json" was our next first guess. So checking on m.Group("/{username}", func() { is required as well. Originally posted by @art-ist in #2908 (comment) |
@art-ist I wrote this PR 3 months ago in response so I cannot fully remember all of the details but... I am absolutely certain that you cannot just block /api/v1/users/{name} and in any case it is pointless as you can just go to /{name} OK I think I'm wrong here and the UI doesn't rely on this path at all. I guess therefore it's fine to be blocked too. |
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oher than the config location this LGBTTOPRTM (looks good and better than the other PR to me).
I think this more general config will serve more users concerned about privacy, a more finegrained control like ONLY_SHOW_USERS_WITH_PUBLIC_REPOS
could be added later as needed
I thought more about this, see #2908 (comment) . In short:
We should probably allow for more flexibility and don't add a bool flag DISABLE_USERS_PAGE
, but USERS_PAGE
with 3 states OPT_OUT
, OPT_IN
, DISABLED
, (where the first is the current behaviour, and the second can be implemented later)
modules/setting/setting.go
Outdated
@@ -265,6 +270,10 @@ var ( | |||
Description: "Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go", | |||
Keywords: "go,git,self-hosted,gitea", | |||
}, | |||
Explore: struct { | |||
RequireSigninView bool `ini:"REQUIRE_SIGNIN_VIEW"` | |||
DisableUsersPage bool `ini:"DISABLE_USERS_PAGE"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on [service.explore]
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about it again again, the opt-in feature can also be realised via a separate flag, so please ignore my above comment
This is an alternative PR to #13687.
Add
[ui.explore]
settings to allow restricting theexplore pages to logged in users only and to disable the users explore page.
The two proposed settings are:
REQUIRE_SIGNIN_VIEW
: Only allows access to the explore pages if theuser is signed in. Also restricts
/api/v1/user/search
/api/v1/users/{username}
/api/v1/users/{username}/repos
/api/v1/users/{username}/heatmap
DISABLE_USERS_PAGE
: Disables the /explore/users pageFix #2908
Close #13687
Signed-off-by: Andrew Thornton [email protected]