Connecting ( Github? ) Oauth to existing chevereto user construct seems to fail if username or email aren't aligned

[Wolfspyre]

So... I THINK this is a chevereto bug, but it's ENTIRELY POSSIBLE that this is more of a documentation miss.


Github has https://github.com/settings/developers "oauth apps" which one doesn't seem to have to explicitly declare any grants for.
as well as https://github.com/settings/apps "Github Apps"

I provisioned an 'oauth' app....

SHOULD THIS WORK?

I've successfully integrated discord and google; both of which I needed to specify the grant scopes...


- on my Chevereto instance, my username is 'Wolfspyre' and I have an associated email address ... lets call it fake@example.com

I was logged in successfully to my chevereto instance.

imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:00:09 +0000] "POST /login HTTP/1.1" 302 10.3.34.3
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:00:09 +0000] "GET /account/two-factor HTTP/1.1" 200 10.3.34.3
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:00:09 +0000] "GET /webmanifest HTTP/1.1" 200 10.3.34.3
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:00:40 +0000] "POST /account/two-factor HTTP/1.1" 302 10.3.34.3
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:00:40 +0000] "GET /peep/Wolfspyre HTTP/1.1" 200 10.3.34.3
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:02:09 +0000] "GET /settings/connections HTTP/1.1" 200 10.3.34.3 
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:04:32 +0000] "GET /connect/github HTTP/1.1" 302  10.3.34.3 
imgHnP  | 10.x.x.100 10.3.34.3 - - [03/Jan/2025:08:04:56 +0000] "GET /connect/github/?code=REDACTEDSTRINGHERE&state=HA-REDACTEDLONGSTRINGHERE HTTP/1.1" 302 10.3.34.3 
imgHnP  | 10.x.x.100 10.3.34.3 - -  [03/Jan/2025:08:04:56 +0000] "GET /connect/github HTTP/1.1" 302 10.3.34.3 
imgHnP  | 10.x.x.100 10.3.34.3 - -  [03/Jan/2025:08:04:57 +0000] "GET/peep/wolfnoble HTTP/1.1" 302 10.3.34.3 
imgHnP  | 10.x.x.100 10.3.34.3 - -  [03/Jan/2025:08:04:57 +0000] "GET /account/email-needed HTTP/1.1" 200 10.3.34.3

As you can see, it seems to me that the underlying problem is that the username wolfnoble (I guess being given by the oauth grant) is different than my chevereto user Wolfspyre (altho my github userid is wolfspyre that doesn't seem to matter. )

So it seems like, for whatever reason, The connection between GitHub and Cheverto's losing the context of 'this auth-request was by cheverto-instance-user-Wolfspyre'

so cheverto instead wants to provision a new user, and so asks me to enter an email to validate the newly provisioned user.

When I enter the email associated with the chevereto user Wolfspyre which Cheverto barks at in the email modal:

@  Add your email address
A confirmation link will be sent to this email with details to activate your account.

the error message that is presented in the submit-email modal is:
Email already being used

(I don't see anything in apache's logs indicating much here, but that's not REALLY surprising.)
it stands to reason that users would have different handles and emails across different services.... so if there's a requirement that these are aligned, that's likely problematic.

Perhaps github's 'oauth' app construct isn't quite sufficient?

 

[Rodolfo]

I enabled GitHub login on demo (oauth app) and it worked for me. I wasn't able to reproduce the error you mention.

On connect if you had an existing login it will try to associate the connection with your logged user. If the connection was already associated with some user, it will logout and continue with the existing binding.

The system doesn't associate existing users via username. The system uses the login_connections table to store the relation user_id (chevereto) to the id from your connector service.

 

[Wolfspyre]

I enabled GitHub login on demo (oauth app) and it worked for me. I wasn't able to reproduce the error you mention.

On connect if you had an existing login it will try to associate the connection with your logged user. If the connection was already associated with some user, it will logout and continue with the existing binding.

The system doesn't associate existing users via username. The system uses the login_connections table to store the relation user_id (chevereto) to the id from your connector service.

aha!

okay!! that makes sense… I’d tried to use the gh login provider and got the error…

under the covers, chevretto’d half-provisioned a user for my gh user; so even though on subsequent attempts, i was attempting to connect gh to my chevereto user, the ‘logout/reauth’ loop got invoked

so… prolly not a bug, perse but rather more of an edge-case wobbler that prolly needs a bit more testing/thinking/noise so as to steer the admin and user in the right direction.

 

[Rodolfo]

You noticed the loop because you tried too soon, it has a 48hrs lock in case the use manages to click the confirmation link.