Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Allow user name suffix for OAuth sources #7014

Open
mxmehl opened this issue May 22, 2019 · 1 comment
Open

Allow user name suffix for OAuth sources #7014

mxmehl opened this issue May 22, 2019 · 1 comment
Labels
topic/authentication type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@mxmehl
Copy link

mxmehl commented May 22, 2019

Description

At our Gitea instance, we would like to introduce a second authentication source next to LDAP, namely Github. However, namespace-wise, we would like to give preference to our current and future LDAP users.

Can Gitea automatically add a suffix to a user name when this user registeres with a specific authentication provider, e.g. that the Github user janedoe becomes janedoe-guest or janedoe-github?

Debian's GitLab supports something like that for external users who are not Debian developers: https://signup.salsa.debian.org/register/guest/
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label May 24, 2019
@mxmehl mxmehl mentioned this issue Jun 7, 2021
Closed
@6543 6543 added good first issue Likely to be an easy fix topic/authentication labels Aug 13, 2021
@6543
Copy link
Member

6543 commented Aug 13, 2021

should be handled around here:

gitea/routers/web/user/auth.go

Line 652 in 3a6edd3

if !createAndHandleCreatedUser(ctx, base.TplName(""), nil, u, &gothUser, setting.OAuth2Client.AccountLinking != setting.OAuth2AccountLinkingDisabled) {

after #16594 got in you have the LoginSource souce to check option against

@asSqr asSqr mentioned this issue Nov 23, 2021
Closed
@seabass-labrax seabass-labrax mentioned this issue Dec 21, 2021
Closed
@mxmehl mxmehl mentioned this issue Aug 19, 2022
Closed
@wxiaoguang wxiaoguang removed the good first issue Likely to be an easy fix label Jul 24, 2023
@mxmehl mxmehl mentioned this issue Nov 21, 2023
Open
project-mirrors-bot-tu bot pushed a commit to project-mirrors/forgejo-as-gitea-fork that referenced this issue Feb 21, 2025
@matrss
[v10.0/forgejo] fix: return 404 for empty repositories (go-gitea#7014)
3eacbfe 
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/7003

Some endpoints (`/api/v1/repos/*/*/raw`, `/api/v1/repos/*/*/media`, ...;
anything that uses both `context.ReferencesGitRepo()` and
`context.RepoRefForAPI` really) returned a 500 when the repository was
completely empty. This resulted in some confusion in
datalad/datalad-usage-dashboard#47 because the
same request for a non-existent file in a repository could sometimes
generate a 404 and sometimes a 500, depending on if the git repository
is initialized at all or not.

Returning a 404 seems more appropriate here, since this isn't an
unexpected internal error, but just another way of not finding the
requested data.

Co-authored-by: Matthias Riße <[email protected]>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7014
Reviewed-by: Gusted <[email protected]>
Co-authored-by: forgejo-backport-action <[email protected]>
Co-committed-by: forgejo-backport-action <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic/authentication type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@lunny @wxiaoguang @mxmehl @6543