Signup with Github shows 422

Resources

FE @annabeldunstone

Summary

A coworker is trying to signup with his github account but after the OAUTH redirect there's a 422 error page and he can't proceed.

He tried this in private window mode but no luck.

Steps to reproduce

• Go to gitlab.com
• Register and choose your github account

What is the current bug behavior?

After redirecting from the Github Oauth page a 422 error page is displayed and user isn't created.

What is the expected correct behavior?

User is created and can access homepage.

Design

---

graphic-422.svg

cc @mydigitalself

added ~480950 ~12980 labels

@marcelo.lebre

I just tested it and it works perfectly fine for me. Could he perhaps provide any further information, screenshots, any errors he's seeing in his JavaScript console?

@mydigitalself Just tried it myself and got the same error. However looking at the url the error is a bit clearer now.

Check the screenshot:

One of the first issues I filed related to this. Here's how to reproduce: https://gitlab.com/gitlab-org/gitlab-ce/issues/728

So what would be the expected user journey here cc @tauriedavis ?

1. Simple error: Sorry, that email address is already in use on GitLab with a link to login with email?
2. More complex - link accounts?
3. Something else?

added shortlist label

We should at the least update the error message to describe what is happening and give the user a way of fixing it.

The other issue says there is an updated error page with better copy but I just tried it and I see the same 422 error message for google as there is for github.

First step would be making sure these error pages get updated. The copy should inform the user what is wrong and provide steps to fix it.

**Signing [in/up] with [Service] failed**

The email associated with your [service] account has already been taken. Please try signing in using your email or username. If you've forgotten your password, try recovering it.

[Sign in] [Recover password]

If none of these options work, try contacting a [GitLab administrator](email link).

@hazelyang Would you able to help with the design and graphic?

As a second step maybe look into ways of linking. I'm not sure of the technical restraints here but Stan mentioned: Automatically link the social account to an existing user based on e-mail address. We can only do this if we trust the OAuth2 provider to give us a valid e-mail address, which may or may not necessarily be true. We should include a parameter in the settings to enable this automatic linkage.

@tauriedavis Will do!

assigned to @hazelyang

Graphic for 422

---

graphic-422.svg

changed milestone to %9.2

added frontend label

removed assignee

added ~974571 label

mentioned in issue #27887 (closed)

Also reported in gitlab-org/gitlab-ce#27887, but since this one contains more info/designs, I've closed that one.

added Deliverable label

Animate it!!

assigned to @annabeldunstone

That would be awesome if the TV was animated haha cc @hazelyang if you have time this release, or we can create a separate issue to improve

Tried to animate the TV on Framer: https://framer.cloud/EOdFD/

Thats awesome @hazelyang! Not sure exactly how you did it in framer but maybe @annabeldunstone can replicate it?

omg I love it. I've never animated an SVG before but now seems like a good time to try!

Locally, the error page shows this (for some reason it's not showing the correct page on production):

cc @stanhu @DouweM

What page is it showing in production?

This 422 page is what I saw when I tested on production https://gitlab.com/gitlab-org/gitlab-ce/issues/29145#note_24998925

@stanhu In production it shows the page @tauriedavis linked to. So this issue really has 2 parts:

1. Get production to show the custom 422 page we already have
2. Update the custom 422 page to match design

It's not blocking me at the moment because I can just continue working on the custom page(views/errors/omniauth_error.html.haml)

I'm wondering if the problem is that this line in the nginx config somehow "intercepts" the 422 error message and renders the default page: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/public/422.html

error_page 422 /422.html;

Perhaps we can remove this line from the nginx config? I suggest enabling nginx in your GDK or testing this change in omnibus.

@to1ne Can you take a look and see if the custom error in the nginx page is causing this issue? I wonder even if we need this line.

mentioned in merge request !11099 (merged)

closed via merge request !11099 (merged)

EDIT: Let's continue the discussion in omnibus-gitlab#2317.

@stanhu I didn't have time yet to thoroughly investigate locally, but this is what I've found so far.

In Ngnix.parse_error_pages custom_error_pages is checked if there are custom pages for the various http status is. If there are the custom page is used, if there isn't the default page is used. In nginx-gitlab-http.conf.erb the error_page statement for each status code is added.

This was added in 17c5dcfb1fc2208581ec3124933e9ff67ecdb6c7 by @ibaum.

We might consider to not add the error_page statement if there isn't a custom page installed. But maybe @ibaum can provide a good reason why it was added like this.

mentioned in issue omnibus-gitlab#2317

mentioned in commit ccb783ea