Support federated login for guest users (OpenID) #64

@tboerger commented on GitHub (Nov 16, 2016):

@stevenroose you shouldn't copy everything, a single reference to the issue should be fine.

@tboerger commented on GitHub (Nov 16, 2016): @stevenroose you shouldn't copy everything, a single reference to the issue should be fine.

GiteaMirror commented

@strk commented on GitHub (Nov 17, 2016):

@sbrl gitea is a fork of gogs made to avoid development being blocked by a single person in charge of accepting contributions. Management of gitea is in the hands of 3 owners elected yearly by a growing number of maintainers (currently 10). See the CONTRIBUTING.md file for further details.

Binary packages, for those who don't want to build from sources, are in the works, see #31

@strk commented on GitHub (Nov 17, 2016): @sbrl `gitea` is a fork of `gogs` made to avoid development being blocked by a single person in charge of accepting contributions. Management of `gitea` is in the hands of 3 owners elected yearly by a growing number of maintainers (currently 10). See the CONTRIBUTING.md file for further details. Binary packages, for those who don't want to build from sources, are in the works, see #31

GiteaMirror commented

@sbrl commented on GitHub (Nov 17, 2016):

Ah right! I might switch when a full release is made then.

@sbrl commented on GitHub (Nov 17, 2016): Ah right! I might switch when a full release is made then.

GiteaMirror commented

@bkcsoft commented on GitHub (Nov 23, 2016):

@tboerger One can always clean it up 😉 (Like I just did)

@bkcsoft commented on GitHub (Nov 23, 2016): @tboerger One can always clean it up 😉 (Like I just did)

GiteaMirror commented

@tscs37 commented on GitHub (Dec 10, 2016):

I'm in favor of adding basic OpenID support and like to also propose OpenID Connect support.

That would allow arbitrary federation from any provider that supports OpenID Connect.

@tscs37 commented on GitHub (Dec 10, 2016): I'm in favor of adding basic OpenID support and like to also propose OpenID Connect support. That would allow arbitrary federation from any provider that supports OpenID Connect.

GiteaMirror commented

@strk commented on GitHub (Dec 10, 2016):

@tscs37 are you up to try at moving some steps toward the implementation of one or the other ?
I've moved the first step for OpenID but it's far from ready (mostly needs UX design), see #271

As per OpenID Connect, do you know of any consumer implementation that does support arbitrary provider support ? I'm asking because I don't and would like to spread the word about its existance.

@strk commented on GitHub (Dec 10, 2016): @tscs37 are you up to try at moving some steps toward the implementation of one or the other ? I've moved the first step for OpenID but it's far from ready (mostly needs UX design), see #271 As per `OpenID Connect`, do you know of any consumer implementation that *does* support arbitrary provider support ? I'm asking because I don't and would like to spread the word about its existance.

GiteaMirror commented

@stevenroose commented on GitHub (Dec 12, 2016):

@strk StackExchange has it (prob not open source). I thought the OSQA had it too, that's an old open-source clone of SE. Or is that basic OpenID?

@stevenroose commented on GitHub (Dec 12, 2016): @strk StackExchange has it (prob not open source). I thought the OSQA had it too, that's an old open-source clone of SE. Or is that basic OpenID?

GiteaMirror commented

@strk commented on GitHub (Dec 12, 2016):

I can log into StackExchange with my OpenID-2.0 provider
(not OAuth based). I dont' have an OpenID-Connect provider
to test with StackExchange, but I suspect only hard-coded
providers would be supported there.

@strk commented on GitHub (Dec 12, 2016): I can log into StackExchange with my OpenID-2.0 provider (not OAuth based). I dont' have an OpenID-Connect provider to test with StackExchange, but I suspect only hard-coded providers would be supported there.

GiteaMirror commented

@stevenroose commented on GitHub (Dec 14, 2016):

Just to copy from @strk 's PR:

The big advantage I would see from having OpenID is as a way of users to login without having been registered. Just like systems like Discuss allow anyone with an OpenID (even though Discuss requires this to be from a small set of providers) to make contributions in the form of issues or (federated) pull requests.

A possible setup that would benefit greatly from OpenID is the case of single-user usage. Gitea as a self-hosted Git homepage in which only one user has commit access, while he can allow anyone to open issues or request pulls with their OpenID (and a CAPTCHA ofc).

@stevenroose commented on GitHub (Dec 14, 2016): Just to copy from @strk 's PR: The big advantage I would see from having OpenID is as a way of users to login without having been registered. Just like systems like Discuss allow anyone with an OpenID (even though Discuss requires this to be from a small set of providers) to make contributions in the form of issues or (federated) pull requests. A possible setup that would benefit greatly from OpenID is the case of single-user usage. Gitea as a self-hosted Git homepage in which only one user has commit access, while he can allow anyone to open issues or request pulls with their OpenID (and a CAPTCHA ofc).

GiteaMirror commented

@strk commented on GitHub (Dec 14, 2016):

Ouch, I already commented in the PR, can we continue there ?

@strk commented on GitHub (Dec 14, 2016): Ouch, I already commented in the PR, can we continue there ?

GiteaMirror commented

2025-11-02 03:07:08 -06:00

@stevenroose commented on GitHub (Mar 19, 2017):

Does #816 allow guest users in some way?

@stevenroose commented on GitHub (Mar 19, 2017): Does #816 allow guest users in some way?

GiteaMirror commented

@strk commented on GitHub (Mar 20, 2017):

@stevenroose I guess you meant #618 (OpenID). It depends on what you mean by "guest users".
Logging in via OpenID still needs you to register as a local user, and confirm your email if the service is configured like that.

The registration step is needed to have a unique identifier on the specific node (rather than using the full OpenID URI as an identifier). Also the code to deal with permissions and teams invitations and such are all based on a local "UserID", so registration is also needed for that (to assign an UserID to an OpenID account).

Doing the registration step also lets you associate multiple OpenID URIs to a single account.

BTW, @stevenroose as you mentioned stackexchange, it also supports OpenID-2.0 so you do can login to Gitea now with "openid.stackexchange.com" as your OpenID URI :)

@strk commented on GitHub (Mar 20, 2017): @stevenroose I guess you meant #618 (OpenID). It depends on what you mean by "guest users". Logging in via OpenID still needs you to register as a local user, and confirm your email if the service is configured like that. The registration step is needed to have a unique identifier on the specific node (rather than using the full OpenID URI as an identifier). Also the code to deal with permissions and teams invitations and such are all based on a local "UserID", so registration is also needed for that (to assign an UserID to an OpenID account). Doing the registration step also lets you associate multiple OpenID URIs to a single account. BTW, @stevenroose as you mentioned stackexchange, it also supports OpenID-2.0 so you do can login to Gitea now with "openid.stackexchange.com" as your OpenID URI :)

GiteaMirror commented

2025-11-02 03:07:08 -06:00

@sbrl commented on GitHub (Mar 20, 2017):

@strk Awesome! So can I restrict auto-registered account to not be able to create repositories too?

@sbrl commented on GitHub (Mar 20, 2017): @strk Awesome! So can I restrict auto-registered account to not be able to create repositories too?

GiteaMirror commented

2025-11-02 03:07:08 -06:00

@strk commented on GitHub (Mar 22, 2017):

To my knowledge there's currently no support to specify default permissions for new users, but it'll be great to add that feature !

@strk commented on GitHub (Mar 22, 2017): To [my knowledge](https://docs.gitea.io/en-us/config-cheat-sheet/) there's currently no support to specify default permissions for new users, but it'll be great to add that feature !

GiteaMirror commented

@stevenroose commented on GitHub (Mar 22, 2017):

@strk @sbrl, yeah that's what I meant with "guest users". Those that only can make issues and submit federated PRs. I.e. not being able to take resources, so that you don't have to trust them not to DOS down your Gitea..

@stevenroose commented on GitHub (Mar 22, 2017): @strk @sbrl, yeah that's what I meant with "guest users". Those that only can make issues and submit federated PRs. I.e. not being able to take resources, so that you don't have to trust them not to DOS down your Gitea..

GiteaMirror commented

@strk commented on GitHub (Mar 22, 2017):

"taking resources" should be clearly defined.
Opening a PR at the bare minimum probably implies opening
a "ticket" record (issue/PR) and probably also the ability
to discuss/react to comments (so more records, issue/pr comments).

I suspect that alone would currently be enough to DOS a Gitea instance.

Anyway I do see also another problem with limiting the space taken
by a user. A fork might probably not take much space until it diverges
too much from the original, but how much is too much ?

I think this discussion (setting limits for users) should be discussed
in a separate ticket, IMHO.

Beside, if I'm not mistaken someone started work on a more fine-grained
set of permissions (check out open issues/PRs)

@strk commented on GitHub (Mar 22, 2017): "taking resources" should be clearly defined. Opening a PR at the *bare* minimum probably implies opening a "ticket" record (issue/PR) and probably also the ability to discuss/react to comments (so more records, issue/pr comments). I suspect that alone would currently be enough to DOS a Gitea instance. Anyway I do see also another problem with limiting the space taken by a user. A fork might probably not take much space until it diverges too much from the original, but how much is too much ? I think this discussion (setting limits for users) should be discussed in a separate ticket, IMHO. Beside, if I'm not mistaken someone started work on a more fine-grained set of permissions (check out open issues/PRs)

GiteaMirror commented

@sbrl commented on GitHub (Mar 23, 2017):

I'd allow the admin to set the amount of space allowed on a per-group basis or something. My main concern is losing all my server's (rather limited) hard drive space.

And can I migrate to gitea from gogs version 0.10.1.0228? I missed the first release of gitea, and according to the website it's not an explicitly supported upgrade path.

@sbrl commented on GitHub (Mar 23, 2017): I'd allow the admin to set the amount of space allowed on a per-group basis or something. My main concern is losing all my server's (rather limited) hard drive space. And can I migrate to gitea from gogs version 0.10.1.0228? I missed the first release of gitea, and according to the website it's not an explicitly supported upgrade path.

GiteaMirror commented