Назад | Перейти на главную страницу

Отдельные учетные записи Gitlab могут входить в систему, но получать недействительные токены

Всего 3 учетных записи в моем экземпляре Gitlab теперь заблокированы мягко.

Несколько месяцев назад мой коллега сообщил, что не может войти в Gitlab (после ввода учетных данных он видит ошибку 403). Все выглядело хорошо с экрана администратора, и в конечном итоге мы «решили» проблему, удалив учетную запись и разрешив им создать новую, а затем восстановив разрешения.

На этой неделе аналогичным образом заблокированы еще 2 аккаунта (моя и третий коллега). Я решил проблему для другого коллеги, удалив его учетную запись, как и раньше, но я очень хочу понять, что происходит, и есть ли способ решить эту проблему без потери учетной записи.

Учетная запись в интерфейсе администратора выглядит хорошо (она не заблокирована, не заблокирована и не ожидает подтверждения по электронной почте).

Доступ к проектам на основе SSH (push and pull) продолжает работать нормально.

До сих пор я пытался отключить учетную запись от ее удостоверения LDAP и преобразовать ее в локальную учетную запись (используя другую учетную запись администратора). Это не привело к изменению поведения, поэтому я не считаю, что здесь виновата интеграция LDAP.

Я в тупике, что делать дальше, поиск в Google дал мне много тем, где люди получают ошибки в войти в систему вместо того, чтобы иметь возможность войти в систему, но не иметь возможности использовать веб-интерфейс.

Я создал еще одну полную учетную запись администратора в веб-интерфейсе и имею root-доступ к ящику, на котором запущен gitlab, поэтому при необходимости могу предоставлять вывод из консоли gitlab-rails и т. Д.

Обновление: я получил новый персональный токен доступа для заблокированной учетной записи из консоли gitlab-rails, и я получаю 403 Forbidden, когда пытаюсь вызвать API (v.s. 401 Unauthorized, когда я кладу мусор для токена). Я думаю, что где-то в базе данных должно быть что-то, что пометило мою учетную запись как заблокированную.

Крики, наконец, выследил этого.

Каким-то образом наша защита Anti-Bot (admin / application_settings / reporting # js-spam-settings) была установлена ​​на 5 IP в неделю. Некоторые из наших пользователей запускали это условие и были заблокированы.

Я не удивлен, что это непрозрачно для клиента (в конце концов, зачем нам указывать боту, что ему нужно делать, чтобы обеспечить меры безопасности?), Но я удивлен, что это не было видно администраторам на веб-интерфейс или в логах!

В любом случае, решение было восстановить по умолчанию 10 / час.