--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I don't know that this is strictly an oauth problem, but I've setup a new gerrit instance using the oauth patch and the plugin. I was able to get this to work great, however, I'm not able to access gerrit via ssh key. I saw something in this thread about oauth ssh not being supported, but I assume this is something different than public key ssh into gerrit using the ssh-key on the user account?The error in sshd_log is "user-not-found"My ssh key is in the database, and my ssh client is attempting to use that key.One thing I notice that's different from older gerrit instances I admin is the "username" field is blank in my preferences, and I can't find a way to set that from the UI. I set it via inserting the username: external id in the db, and now ssh works.
Maybe this is something to fix in the ssh-key add instead of in the oauth registration?
I don't know that this is strictly an oauth problem, but I've setup a new gerrit instance using the oauth patch and the plugin. I was able to get this to work great, however, I'm not able to access gerrit via ssh key. I saw something in this thread about oauth ssh not being supported, but I assume this is something different than public key ssh into gerrit using the ssh-key on the user account?The error in sshd_log is "user-not-found"My ssh key is in the database, and my ssh client is attempting to use that key.One thing I notice that's different from older gerrit instances I admin is the "username" field is blank in my preferences, and I can't find a way to set that from the UI. I set it via inserting the username: external id in the db, and now ssh works.
Sorry it took me a while before I had a chance to test this out. I tried it. The user can register a new account logging in via Google, but they still didn't have a "username:" entry in account_external_ids
The Full Name in their settings was also not set.
Am Freitag, 13. März 2015 21:28:45 UTC+1 schrieb Kelly Campbell:Sorry it took me a while before I had a chance to test this out. I tried it. The user can register a new account logging in via Google, but they still didn't have a "username:" entry in account_external_idsI just re-checked it on a fresh site, on 2.10.1 with the latest pluginversion. Works here as expected: username is set during registration.ACCOUNT_EXTERNAL_IDS has two entries: OpenID Connect useridentity and username.Can you check if alias is set for the user on the Google account side?Username is mapped to alias and this is optional attribute.
After abandoning the approach to support one single OAuth authenticationscheme in Gerrit core, revamped attempt was started to support multipleOAuth providers.The idea is to restrict the core to only expose OAuth extension point anduse Gerrit plugin concept to provide support for multiple OAuth providers,like it was done with Gerrit scripting plugin providers.This change exposes such extension point [1] and offer provider selectiondilaog in case multiple OAuth provider plugins were deployed: [2].Google OAuth2 provider plugin is available [3] that depends on this extensionpoint: [2]. Further OAuth provider plugins will follow.TODO:* support anonymous browsing, with redirect to login dialog when required
* support linking different OAuth identities to existing account
Hi David,I have to say ... amazing job :-) well done !
One *very important* think we are still missing is Shawn's feedback though.
I think that the key was really introducing everything external through plugin, so that for Gerrit is a simple extension point with no extra deps.Again … plugin approach is the winner :-)
One question: where to attach the github plugin now?Option a) extend the Gerrit OAuth provider which includes GitHub auth as well [1]
Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?
- Scopes configuration- Profile import- Repositories import and replication- Pull requests imported as Change + PatchSets- Group backend for GitHub organisation and teams- Template engine with configurable wizard post-login… and more stuff is planned.IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?
But then how to use the gerrit-oauth-provider and link to it from the github plugin?
On 23 Mar 2015, at 10:49, David Ostrovsky <david.o...@gmail.com> wrote:
Am Montag, 23. März 2015 11:42:28 UTC+1 schrieb lucamilanesio:Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?Nope.
- Scopes configuration- Profile import- Repositories import and replication- Pull requests imported as Change + PatchSets- Group backend for GitHub organisation and teams- Template engine with configurable wizard post-login… and more stuff is planned.IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?Yes. That should stay in GitHub plugin.
But then how to use the gerrit-oauth-provider and link to it from the github plugin?This is a good question. When we don't find an easy way to re-user the gerrit-oauth-providerin GitHub plugin, we could still have two different implementation: OAuth only (like old OpenIDstuff) and full fledged GH integration provided by GitHub plugin that you've mentioned above.
On 23 Mar 2015, at 10:49, David Ostrovsky <david.o...@gmail.com> wrote:
Am Montag, 23. März 2015 11:42:28 UTC+1 schrieb lucamilanesio:Exactly, but the problem is: are you willing to “pollute” the gerrit-oauth-provider with all the stuff that is in github plugin?Nope.Same here :-)- Scopes configuration- Profile import- Repositories import and replication- Pull requests imported as Change + PatchSets- Group backend for GitHub organisation and teams- Template engine with configurable wizard post-login… and more stuff is planned.IMHO all that stuff is *so* GitHub related that it would have too much of a polluting effect on gerrit-oauth-provider, isn’t it?Yes. That should stay in GitHub plugin.Yep.But then how to use the gerrit-oauth-provider and link to it from the github plugin?This is a good question. When we don't find an easy way to re-user the gerrit-oauth-providerin GitHub plugin, we could still have two different implementation: OAuth only (like old OpenIDstuff) and full fledged GH integration provided by GitHub plugin that you've mentioned above.That was my first initial feeling … even if I wouldn’t like it that much :-(Is there any way to do something similar to the its-base / its-jira plugins ? That including the gerrit-oauth-provider at compile time to github to effectively reuse the OAuth implementation and avoid duplication?Best would be plugin-to-plugin dependency loading …
but I think we’ve already discussed that topic isn’t it ?
I've spent quite some time to implement cross-plugin-dependency feature: [1],and this series was in very good shape (like all my changes ;-), but ... it wasn'tmerged in the end.
* support linking different OAuth identities to existing accountPartially done: Google OAuth accounts can be linked to OpenID accounts.
On Monday, March 23, 2015 at 8:44:03 AM UTC+1, David Ostrovsky wrote:* support linking different OAuth identities to existing accountPartially done: Google OAuth accounts can be linked to OpenID accounts.
How do you use that?
After abandoning the approach to support one single OAuth authenticationscheme in Gerrit core, revamped attempt was started to support multipleOAuth providers.The idea is to restrict the core to only expose OAuth extension point anduse Gerrit plugin concept to provide support for multiple OAuth providers,like it was done with Gerrit scripting plugin providers.
TODO:* support anonymous browsing, with redirect to login dialog when required
* support linking different OAuth identities to existing account
Are we done? For new sites yes, for existing sites, that depend on OpenID, not.Problem:Unfortunately this is still not sufficient migration path for Gerrit installations thatare using OpenID atm. What is needed is hybrid OpenID/OAuth authenticationscheme. This authentication option is indispensable for all Gerrit installationsin the wild that currently depend on OpenID, and with Google's end of life ofOpenID are screwed up, as only part of their user base is using deprecatedOpenID provider, while a substantial part of their user base is still using saneOpenID providers.Solution:Offer aforementioned hybrid OpenID/OAuth authentication option and supportlinking user identities across different authentication scheme (OpenID -> Oauth).
Ideally, this feature should be available (and released) before April 20, 2015.