GitLab OmniAuth plugin

I rebuilt the instance and now it shows v0.0.3. But I still can’t login from Gitlab: it proposes me to use a different username. This is weird.

I tried running the code from the console:

::PluginStore.get("gl", "gl_uid_hellekin")
=> nil
existing_user = User.where(email: email).first
=> User ...
::PluginStore.set("gl", "gl_uid_hellekin", {user_id: existing_user.id})

Then tried to login from gitlab again. No luck.

BTW, I submitted an MR to fix a minor issue.

Could it be that you have multiple e-mails in GitLab? I think it only captures the one you set as primary.

I have emails using +, e.g., user+foo@example.org. Would that interfere?

No, but i tried with a new GitLab account and I can reproduce your issue. Investigating.

1 Like

Any progress on this @axil?

Hi @hellekin seems I misunderstood your issue. Here’s what I did:

  1. Create a new account in GitLab.com
  2. Create a new account in forum.gitlab.com with the same e-mail as above
  3. Logout from forum
  4. Login using GitLab OAuth
  5. 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 :confused:

Did you try to use a different regular e-mail (not user+foo@example.org)?

Hi @hellekin seems I misunderstood your issue. Here’s what I did:

I reproduced the above on talk.devuan.org:

  1. Create a new account in talk.
  2. Logout from talk.
  3. Create a new account in gitlab, using the same email (and username)
  4. 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 can now login successfully!

2 Likes

Cool that you got it working! Should these issues be fixed in the plugin or is it a server-side issue?

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.

1 Like

Hmm, I’m wondering how different the the other oauth plugins are.

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)

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

2 Likes

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:

Faraday::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed)
/usr/local/lib/ruby/2.3.0/net/http.rb:933:in `connect_nonblock’

Both my Gitlab site and my Discourse site have Treasury dept signed SSL certs.

Did you add the Treasury dept root certificate to the docker container certificate store?

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.

Thanks for the help

I added the root/int certs, and I see in the log they get added, but the error remains the same.

run:

  • exec: echo “Beginning of custom commands”

  • file:
    path: /usr/local/share/ca-certificates/treasury-root.crt
    chmod: 444
    contents: |
    -----BEGIN CERTIFICATE-----

    -----END CERTIFICATE-----
    
  • exec: /usr/sbin/update-ca-certificates

  • file:
    path: /usr/local/share/ca-certificates/treasury-int.crt
    chmod: 444
    contents: |
    -----BEGIN CERTIFICATE-----

    -----END CERTIFICATE-----
    
  • exec: /usr/sbin/update-ca-certificates

  • exec: echo “End of custom commands”

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

http://mislav.net/2013/07/ruby-openssl/

Of course it’s 3 years old, so not sure how relevant it is now.

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"
3 Likes

@mntbighker thanks a lot for getting back with the solution :slight_smile:

Hi all, I am getting this error while installing the plugin. Just followed the tutorial and added it to after_code hook.

It throws this error when running 'bundle exec rake db:migrate after cloning etc.

You are specifying the gem omniauth-gitlab in /var/www/discourse/plugins/discourse-omniauth-gitlab/plugin.rb, however it does not exist!

Thanks!