CODEWITHSUNDEEP
cookiesgitlabuser-accounts
maxemilian
maxemilian

Reputation: 414

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

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?

Upvotes: 19

Views: 71047

Answers (10)

mahdi
mahdi

Reputation: 942

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.

Upvotes: 1

DustWolf
DustWolf

Reputation: 586

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

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

Upvotes: 1

vahidpirian
vahidpirian

Reputation: 17

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.

Upvotes: 1

Torben Kohlmeier
Torben Kohlmeier

Reputation: 6783

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

Upvotes: 1

J&#252;rgen Albersdorfer
J&#252;rgen Albersdorfer

Reputation: 11

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

Upvotes: 1

Raymond
Raymond

Reputation: 57

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.

Upvotes: 1

Jacob Aguilar
Jacob Aguilar

Reputation: 31

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

Upvotes: 1

Mayank Kalbhor
Mayank Kalbhor

Reputation: 49

Empty Cache and Hard Reload on chrome will do the trick

Upvotes: 0

lionel
lionel

Reputation: 355

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

Upvotes: 22

VonC
VonC

Reputation: 1324238

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://gitlab.com/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.

Upvotes: 6

Related Questions