Create a new account in forum.gitlab.com with the same e-mail as above
Logout from forum
Login using GitLab OAuth
Successfully logged in to forum.gitlab.com, the accounts were associated, Discourse even pulled my gravatar
Even if you don’t manually create a new user in Discourse and use the login using gitlab-omniauth, you are asked to create a new user with the e-mail from GitLab.
I can’t seem to reproduce it
Did you try to use a different regular e-mail (not user+foo@example.org)?
Create a new account in gitlab, using the same email (and username)
Login to talk “using gitlab”.
What happens: user logs in properly. \o/
BUT
Now, I have existing accounts on the Discourse instance, who existed
prior to installing the plugin, with a matching Gitlab account, who won’t login. Instead, they ask to create “user1” and claim the
username is already taken. Same username, same email on the Gitlab.
Even if you don’t manually create a new user in Discourse and use the login using gitlab-omniauth, you are asked to create a new user with the e-mail from GitLab.
That’s the normal case, when you have an existing Gitlab account and no
Discourse account. Works fine.
Did you try to use a different regular e-mail (not user+foo@example.org)?
Yes, I changed the email in gitlab and discourse to remove +, although
this influencing the process would be a bug. Same same.
Anyway I think this might be the source of the problem. I have in
the database emails like user+foo@example.net. I suspect that the
auth process is assuming unique emails, but the verification drops
the +, making unique emails collide. Is that possible? That would
explain why the accounts with user@example.org can’t login when user+foo@example.org exists as well. Basically the code would expect
a single User object but instead receive an Array of them.
I had a look at storage. I should have done that earlier, but well, I was consuming the software, not really into it. Of course there was a stale record for my gl_uid associated with another (deleted) discourse account. The plugin was silently failing.
I’m looking into fixing these issues. I found another one: you need to check the validity of the username. I had a record with a gitlab user mr.foo, and the key was gl_uid_ instead of gl_uid_123 probably because the period is invalid in Discourse usernames. I fixed the entry manually pending another login to see whether that causes a problem.
I guess the plugin could do some consistency check on error but I have the impression as well that it’s not really its role either.
There’s an obvious use-case that could be addressed: applications usually have a different notion of what a valid username is. Discourse and Gitlab disagree on the presence of a period in a username: when a Gitlab user named john.doe tries to connect to Discourse, apparently what happens is that Discourse, unable to validate the username, return an inconsistent result (where the gl_uid is empty), leaving the account without a possibility to login (as the username is invalid, and the email is registered into the PluginStore without reference to the original gl_uid: in effect, a new login will tell the user the email is already taken and goto fail.
Now this is interesting because it converges to my case, where a random failure remains quiet, and the plugin doesn’t differentiate between a login failure and an internal error. Validating the fields (or invalidating them rather) should report to the plugin somehow.
Sorry to be a bit dense and confused. I’m thinking aloud. Better let the code talk.
Discourse will just ask you for a new username while it should still remember that uid. My oauth providers won’t gives a email so the users have to type their account information on their own after authenticated from a provider. In the meantime, I am so sure Discourse will remember the uid.
I would say…you have to try whether it’s working in a clean install (I know it’s painful to debug this)
@axilafter_create_account takes previous information from the return value of after_authenticate. These previous information comes along with the session[:authentication].
The most chance is oauth strategy fails to return a valid uid thus the code set a nil in the extra_data. In the end, without the uid, the code can’t set a proper key in the plugin row.
I have the plugin set up, and I’m getting the popup. It begins to authenticate, and if you are already logged in with Gitlab you get an Auth or Deny choice. If I select Authorize, the browser says the site is unable to handle the request. And the Discourse error log shows:
No. In the case of the Discourse docker image, where is that located? What commands need to be run after it’s added? Do I need to modify any files or just add the cert to the directory? I think I know where I can grab the root cert.
It’s worth a mention that googling for the Faraday::SSLError you find a fair number of people who claim updating to a later ruby resolved the error. This is in other rails apps of course.
I tried adding the Gitlab server SSL cert instead of the Treasury root cert and still had the same problem.
I also found this (apparently a common problem with SSL/ruby):
I finally have this working. Here is the app.yml with the entries to get the 175 NASA certs imported.
## GitLab OmniAuth settings
GITLAB_APP_ID: foo
GITLAB_SECRET: bar
GITLAB_URL: https://xxx.yyy.zzz
## The Docker container is stateless; all data is stored in /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://gitlab.com/gitlab-org/discourse-omniauth-gitlab.git
run:
- exec: echo "Beginning of custom commands"
## If you want to set the 'From' email address for your first registration, uncomment and change:
## After getting the first signup email, re-comment the line. It only needs to run once.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: apt install unzip
- exec: unzip /shared/ssl/NTAM_Collection_Ubuntu_2016.2.zip -d /usr/local/share/ca-certificates/
- exec: chmod 444 /usr/local/share/ca-certificates/*
- exec: c_rehash /usr/local/share/ca-certificates
- exec: update-ca-certificates
- exec: echo "End of custom commands"
Any update on this plugin? I’m trying to make it working on Discourse V2.7.13 but when I click on the “connect to GitLab” button it redirects me to a weird URL “oauth…”. I don’t really know what’s wrong
