Gitlab account acces error: "422 The change you requested was rejected."
Asked Answered
T

10

17

This question asked by coderss but restarting the computer seems to noneffective.

422 The change you requested was rejected. Make sure you have access to the thing you tried to change. Please contact your GitLab administrator if you think this is a mistake.

I have above error in Firefox under Linux but I have access in Chromium. That's looks like typical cookie problem.

I tried clear all Gitlab related cookies then restarted computer without any new sign in attempt. and restarted computer :) yeah I just try

But still same error, same browser.

How can I handle this problem?

This error also occurs at forgot password section and in private tab of Firefox.

Is there another Gitlab related cookie?

Trevortrevorr answered 21/1, 2021 at 4:21 Comment(1)
I wouldn't prefer cleaning all cookies under preferences-->Privacy & Security-->Cookies and Site Data> clear data. I intent to easy way for unless cleaning all cookies but even if clean all cokies and site data and Chached web content doesn't work. It is amazing. I cleaned everything but Still taking 422.Trevortrevorr
Q
20

The issue should be fixed not only with cookies as discribed, but also with a correction of time system. I faced exactly the same problem: unable to connect with Firefox, even with a reset of cookies, but I was able to connect with Chrome. (That sounds strange because my clock system was false even on Chrome.)

The solution came with this very short explanation:

"it's was because my local time zone wasn't set up properly (and was messing with cookies)" Source: https://www.reddit.com/r/gitlab/comments/cv7pov/422_error_on_wwwgitlabcomuserssignin_and/ey7l7lz?utm_source=share&utm_medium=web2x&context=3

Quinone answered 30/3, 2021 at 13:27 Comment(3)
Yeah, I have a problem with my distro's timer which little broken. I couldn't set a time zone then forced to set a time trivial. It has still broken but GitLab work nowadays.Trevortrevorr
Thanks. I also have this problem, because I used Windows and Ubuntu on the same machine. Whenever I start Windows then restart to Ubuntu, the clock is wrong because of two OS difference in interpreting local clock.Worker
Thanks, had this issue also. Running a Windows guest on an Ubuntu host. Time was correct on the host and in the guest, but guest timezone was set to PST, not EST. After correcting timezone and updating time, works just fine.Cleruchy
F
6

This was followed by issue 35447 and issue 40898.

The last one included:

Ok, I suspect the issue here for many people is that the GitLab session cookie is set to Secure here: https://gitlab.com/gitlab-org/gitlab-ce/blob/9c491bc628f5a72424b82bb01e2457150bf2e71c/config/initializers/session_store.rb#L25

Setting the right SSL headers fixes the problem.

If, for some reason, the connection doesn't appear to be an HTTPS connection, Rails won't send a cookie, and the client won't be able to login. You may be able to confirm this by checking the response headers in the GET /users/sign_in endpoint: if you see a _gitlab_session cookie being sent the first time you load the page, then things are working properly.

And:

JuKu JuKu @JuKu · 1 year ago

Solution for HaProxy:

Add these line to your frontend: reqadd X-Forwarded-Proto:\ http

After this change, it worked for me.

See also: https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04

That would avoid the dreaded:

https://static.mcmap.net/file/mcmap/ZG-AbGLDKwfnZ7-sWV9QWRft/gitlab-org/gitlab-foss/uploads/7ef0738b531b0475e1f52a6fa700917a/Unbenannt101.PNG

But it depends on the type of GitLab used (gitlab.com or an on-premise GitLab, and the type of Web server used)

For example, issue 53085 refers to issue 54493:

The group had internal availability, while one of it's projects was public (not the one I was having so much trouble with, which was private).

Making the group public solved the problem.


The OP maxemilian reports in the comments it is working now with Firefox on Manjaro:

I checked my updates diary, but only zoom matches between Firefox access time successfully.
I pretty sure this was related to GitLab login code. Suspicious dates (Jan 6- Jan 21 and Feb 3- Feb 6).
I think This update done by GitLab the dates between Feb 3- Feb 6.

Flabby answered 21/1, 2021 at 8:14 Comment(5)
Thank you for amazing compilation. I glanced all of them but I coudn't get access. Particularly Nicola Luraghi solution looks fit my situation. Still giving error. I even cleaned everything in FirefoxTrevortrevorr
@Trevortrevorr Darn. That is frustrating! Does it persists with a different computer?Flabby
I can sign in with firefox on android. No problem. But I deleted everything on my manjaro related Firefox then reinstalled but still same error. I have dummy faceTrevortrevorr
It's working now! Solved <br /> I checked my updates diary, but only zoom matches between Firefox access time successfully. <br /> I pretty sure this was related to GitLab login code. Suspicious dates (Jan 6- Jan 21 and Feb 3- Feb 6). I think This update done by GitLab the dates between Feb 3- Feb 6<br /> BTW, thank you for any help.Trevortrevorr
@Max What was missing in this answer? I understand Lionel's answer adds to it, but I still provided the initial references.Flabby
S
1

In my case, server time was late and I had to change the time, then restart the server and reconfigure the gitlab.

Change server time

sudo timedatectl set-time "06:24:00"
sudo timedatectl set-time "2020-04-23"
sudo hwclock --systohc

Reconfigure Gitlab.

sudo gitlab-ctl reconfigure
Sustentacular answered 14/4, 2022 at 4:4 Comment(3)
This seems to be saying the same thing as user lionel's answer.Gaw
@Gaw This answer is suggesting you check the time on the gitlab server I found this helpful; due to a power outage, our gitlab server had a date reset from 2022 to 2010. Fixing up the server date/time allowed me to log back in! Note, I didn't have issues with command-line commits; only logging into the GUI.Mutilate
I see - same root cause, different solution. (The clocks need to be in sync.)Gaw
B
1

For me it was the VPN. If you are connected to a VPN set to a different timezone, turn it off, clear the cookies and you should be able to connect.

Bagwig answered 6/10, 2022 at 7:51 Comment(0)
K
1

In my case I was trying to fetch changes using a Git command and also got this error. It turned out that I was using the wrong URL. The .git suffix was missing. Curiously it worked the first time.

so from

https://<gitlab-url>/<user>/<repo>

to

https://<gitlab-url>/<user>/<repo>.git  //<-- notice .git ending
Kirwin answered 24/1, 2023 at 10:45 Comment(0)
K
1

In my case, the client date/time was set wrong. Correcting the client computer time (activating ntp) did solve the issue.

Kape answered 8/5, 2023 at 13:11 Comment(0)
V
1

I had the same problem. And I tried all of your suggestions, but there was no point in doing them. Eventually, I realized that It was about caching my own CDN provider. I turned the catching off, so it was resolved.

Vocoid answered 21/9, 2023 at 5:7 Comment(0)
S
1

In my case this was caused by the git on CentOS 7 being too old.

Solved with: https://serverfault.com/a/813293/223931

Shannon answered 18/12, 2023 at 11:55 Comment(0)
S
0

Empty Cache and Hard Reload on chrome will do the trick

Stealth answered 30/5, 2022 at 17:41 Comment(0)
I
0

for me it was just about using the https instead of http endpoint. I installed the Gitlab on-premises inside the Kubernetes cluster using its official helm chart, so it created an endpoint for me.

Interventionist answered 21/1, 2024 at 23:3 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.