Gitlab ошибка 422

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?

asked Jan 21, 2021 at 4:21

maxemilian's user avatar

1

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.

answered Jan 21, 2021 at 8:14

VonC's user avatar

VonCVonC

1.3m530 gold badges4425 silver badges5265 bronze badges

5

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

answered Apr 14, 2022 at 4:04

Jacob Aguilar's user avatar

3

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

Eliav Louski's user avatar

Eliav Louski

3,6632 gold badges30 silver badges54 bronze badges

answered Jan 24 at 10:45

Torben Kohlmeier's user avatar

Torben KohlmeierTorben Kohlmeier

6,7131 gold badge15 silver badges15 bronze badges

Empty Cache and Hard Reload on chrome will do the trick

answered May 30, 2022 at 17:41

Mayank Kalbhor's user avatar

0

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.

answered Oct 6, 2022 at 7:51

Raymond's user avatar

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

answered May 8 at 13:11

Jürgen Albersdorfer's user avatar

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.

answered 6 hours ago

vahidpirian's user avatar

Skip to content

Error 422 The change you requested was rejected on login

Summary

Similar to #35447 (closed), however I have a base local gitlab install, revertted back to super basic defaults in gitlab.rb configuration (only serving up HTTP). Uncertain when, (gone through a few gitlab-ce upgrades without actually logging into the web UI..), suddenly a POST to /users/sign_in results in 422 «The change you requested was rejected on login»

Steps to reproduce

TBD greenfield reproduction … but for my instance, simply trying to AUTH using web UI as a local admin account results in this error.

Example Project

TBD

What is the current bug behavior?

  1. gitlab-ctl status shows all services up
  2. user visits http://gitlab-URI:80
  3. server redirects to http://gitlab-URI/users/sign_in
  4. user enters LOCAL login credentials (in my case it’s a local admin user to gitlab)
  5. page goes: POST /users/sign_in HTTP/1.1 422

What is the expected correct behavior?

successful auth
(the error message hints that «I may not have access to the thing I tried to change» … but I’m auth’ing as a local admin user, also even tried the root account, and even some bogus FOO/BAR account! all the same result

is this some convoluted way of saying «invalid user/pass»? — I doubt my primary user password is wrong however… since it’s saved and I can confirm by manually typing too.

Relevant logs and/or screenshots

 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.

services are all up

# sudo gitlab-ctl status
run: gitaly: (pid 12534) 260s; run: log: (pid 892) 300573s
run: gitlab-monitor: (pid 12548) 260s; run: log: (pid 906) 300573s
run: gitlab-workhorse: (pid 12517) 261s; run: log: (pid 893) 300573s
run: logrotate: (pid 12558) 259s; run: log: (pid 894) 300573s
run: nginx: (pid 12564) 259s; run: log: (pid 885) 300573s
run: node-exporter: (pid 12572) 258s; run: log: (pid 886) 300573s
run: postgres-exporter: (pid 12578) 258s; run: log: (pid 896) 300573s
run: postgresql: (pid 11895) 307s; run: log: (pid 916) 300573s
run: prometheus: (pid 12586) 257s; run: log: (pid 919) 300573s
run: redis: (pid 11897) 307s; run: log: (pid 891) 300573s
run: redis-exporter: (pid 12598) 257s; run: log: (pid 897) 300573s
run: sidekiq: (pid 12609) 257s; run: log: (pid 902) 300573s
run: unicorn: (pid 12616) 256s; run: log: (pid 900) 300573s

/var/log/gitlab/nginx/gitlab_access.log shows:

1.0.0.6 - - [06/Dec/2017:22:03:20 -0500] "POST /users/sign_in HTTP/1.1" 422 2912 "http://gitlab-URI/users/sign_in" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0"

nothing from gitlab_error.log, … also sanity checked other logs for possible AUTH failures or something else, but nothing of interest or more additional logs

/var/log/gitlab# for dir in $(ls -1 .); do echo $dir; ls -alt $dir/ | head -5; done

My configuration for gitlab is super minimal

fermulator@fermmy-git:~$ sudo egrep -v "#" /etc/gitlab/gitlab.rb

external_url 'http://gitlab-URI:80'

git_data_dirs({
  "default": {
    "path": "/mnt/storage/git-data"
  }
})

Output of checks

n/a

Results of GitLab environment info

# gitlab-rake gitlab:env:info

System information
System:		Ubuntu 14.04
Current User:	git
Using RVM:	no
Ruby Version:	2.3.5p376
Gem Version:	2.6.13
Bundler Version:1.13.7
Rake Version:	12.1.0
Redis Version:	3.2.5
Git Version:	2.13.6
Sidekiq Version:5.0.4
Go Version:	unknown

GitLab information
Version:	10.2.3
Revision:	3141105
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		http://<GIT-URI>
HTTP Clone URL:	http://<GIT-URI>/some-group/some-project.git
SSH Clone URL:	git@<GIT-URI>:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	5.9.4
Repository storage paths:
- default: 	/mnt/storage/git-data/repositories
Hooks:		/opt/gitlab/embedded/service/gitlab-shell/hooks
Git:		/opt/gitlab/embedded/bin/git

Results of GitLab application Check

# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab Shell ...

GitLab Shell version >= 5.9.4 ? ... OK (5.9.4)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ... 
2/1 ... ok
2/2 ... ok
2/3 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK

Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Reply by email is disabled in config/gitlab.yml
Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ... 
2/1 ... yes
2/2 ... yes
2/3 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.3.5)
Git version >= 2.7.3 ? ... yes (2.13.6)
Git user has default SSH configuration? ... yes
Active users: ... 3

Checking GitLab ... Finished

Possible fixes

UNKNOWN

Edited by Fermulator

Solution 1

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

Solution 2

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.

Comments

  • 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?

Recents

Firefox 68.0.1. I can’t sign in to Gitlab. I get an HTTP 422 error with the following message:

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.

Cleaning all data in browser doesn’t help.

With Chromium I don’t have any problems and I can sign in as expected.

Run5k's user avatar

Run5k

15.8k24 gold badges50 silver badges63 bronze badges

asked Aug 10, 2019 at 22:36

Teoyaomqui's user avatar

Closed. Firefox fixed it self.

answered Aug 14, 2019 at 23:14

Teoyaomqui's user avatar

TeoyaomquiTeoyaomqui

511 silver badge8 bronze badges

1

There 2 choice:

  1. Allowe cookies (without 3rd party cookies) on Firefox
  2. Set or resetting system clock

These Work for me.

answered Feb 17, 2020 at 10:27

shgnInc's user avatar

shgnIncshgnInc

4357 silver badges17 bronze badges

You must log in to answer this question.

Not the answer you’re looking for? Browse other questions tagged

.

Этот вопрос задан coderss , но перезагрузка компьютера кажется неэффективной.

422 Запрошенное вами изменение было отклонено. Убедитесь, что у вас есть доступ к тому, что вы пытались изменить. Если вы считаете, что это ошибка, обратитесь к администратору GitLab.

У меня есть указанная выше ошибка в Firefox под Linux, но у меня есть доступ в Chromium. Это похоже на типичную проблему с файлами cookie.

Я попытался очистить все файлы cookie, связанные с Gitlab, затем перезагрузил компьютер без новой попытки входа. и перезагрузил компьютер :) да, я просто пробую

Но все та же ошибка, тот же браузер.

Как я могу справиться с этой проблемой?

Эта ошибка также возникает в разделе забытого пароля и на частной вкладке Firefox.

Есть ли еще один файл cookie, связанный с Gitlab?

1 ответ

Лучший ответ

За этим последовали проблема 35447 и проблема 40898.

Последний включал:

Хорошо, я подозреваю, что проблема здесь для многих заключается в том, что файл cookie сеанса GitLab настроен на Secure здесь: https://gitlab.com/gitlab-org/gitlab-ce/blob/9c491bc628f5a72424b82bb01e2457150bf2e71c/config/initializers.rsession_store_store

Установка правильных заголовков SSL решает проблему.

Если по какой-то причине соединение не похоже на HTTPS-соединение, Rails не будет отправлять cookie, и клиент не сможет войти в систему. Вы можете подтвердить это, проверив заголовки ответа в конечной точке GET /users/sign_in: если вы видите, что файл cookie _gitlab_session отправляется при первой загрузке страницы, значит, все работает правильно.

А также:

JuKu JuKu @JuKu · 1 год назад

Решение для HaProxy:

Добавьте эту строку в свой интерфейс: reqadd X-Forwarded-Proto: \ http

После этого изменения у меня все заработало.

См. Также: https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04

Это позволит избежать ужасного:

https://gitlab.com/gitlab-org/gitlab-foss/uploads/7ef0738b531b0475e1f52a6fa700917a/Unbenannt101.PNG

Но это зависит от типа используемого GitLab (gitlab.com или локальный GitLab, а также от типа используемого веб-сервера).

Например, проблема 53085 относится к проблема 54493:

У группы была внутренняя доступность, в то время как один из ее проектов был публичным (а не тем, с которым у меня было столько проблем, которое было частным).

Публикация группы решила проблему.


Отчет OP maxemilian в комментарии, теперь он работает с Firefox на Manjaro:

Я проверил свой дневник обновлений, но успешно увеличил масштаб только совпадений между временем доступа Firefox.
Я почти уверен, что это было связано с кодом входа в GitLab. Подозрительные даты (6 января — 21 января и 3 февраля — 6 февраля).
Я думаю, что это обновление сделано GitLab в период с 3 по 6 февраля.


1

VonC
6 Фев 2021 в 10:54

Понравилась статья? Поделить с друзьями:
  • Git ошибка при push
  • Gitlab ошибка 404
  • Gitlab 502 ошибка
  • Github ошибка авторизации
  • Github как сообщить об ошибке