Support federated login for guest users (OpenID)

[stevenroose]

From @stevenroose on May 26, 2015 9:5

It bothers many that they have to enter a full form of personal information in order to just file a bug or make a feature request.
OpenID support can fix this and allows guest users to login with they GitHub of Google account f.e.

Ideally, it would also be possible to restrict these "guest"/external users to only be able to make create issues and pull requests and not have their own repositories.

Copied from original issue: gogs/gogs#1297

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39298589-support-federated-login-for-guest-users-openid?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).

[sbrl]

Waaaaat? I don't understand what's going on here. What's gitea? Why has it been forked? Is gogs still a thing?

To answer [this comment], I don't think I can since I don't have go installed, I don't know go, I don't understand the go package system, and I don't understand openid 😕 😞

???

[tboerger]

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

[strk]

@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

[sbrl]

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

[bkcsoft]

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

[tscs37]

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.

[strk]

@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.

[stevenroose]

@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?

[strk]

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.

[stevenroose]

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).

[strk]

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

[stevenroose]

Does #816 allow guest users in some way?

[strk]

@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 :)

[sbrl]

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

[strk]

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

[stevenroose]

@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..

[strk]

"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)

[sbrl]

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.

[strk]

@sbrl see also #1377 for setting users limits (and use the forum or IRC chat or file another issue to know about upgrade)