I was trying to add a new Application to my user’s settings. Namely, WakaTime, after adding the app in my user settings and authorizing the App in WakaTime, it failed with an error 500. Afterwards I cannot use my user account, it returns 403 for all HTTP requests.
My user is still an admin. So I think somehow it got corrupted. I tried to enter the rails console, but I’m not familiar with the Gitlab rails app to know to undo whatever it might have happened to corrupt my user.
Any ideas of what to look? I still have access to the my instance via SSH, and another user account which is also admin. But I would like to keep using my user since I’ve done thousands of contributions, comments, etc.
Well… This is weird. With the other admin user, I tried to create a new user for myself. In order to that, I removed one on my emails in the old user. It seems that this operation unlocked my old user and I can now use it once more.
I tried once more to add WakaTime to my user’s applications. Again it broke my user. This time, editing the user from another account hasn’t solved the issue.
Just wondering, was your account associated with a PAM password (/etc/password) database or was the account internal to GitLab? I noticed that you mentioned SSH, which has typically been a Linux/Unix tool for remote administration.Consequently, as of one of the more recent Windows 10 patches ssh is now available natively to Windows 10, as well.
Perhaps deleting some email reduced file system usage back down from 100%, enabling your PAM account to authenticate and logon? This is a security thing in Linux and Unix.
The auto-unlocking can also be a feature of the system (OS) hardening. If you have too many failed attempts on your system your system can be configured to perform both of the following:
Lock the user account, and
Unlock the account some amount of time later (typically 15 minutes, but it can be changed).
Indeed I have SSH access, but I usually use HTTPS to pull/push. I don’t use Windows, though
My Gitlab Account is internal, so PAM doesn’t apply. Other users were unaffected. I simply stopped trying to link my account to WakaTime. They suggested we should enable rate limits in the Gitlab Admin page and we did, but still users that linked they accounts to WakaTime were banned for about 10 minutes afterwards.
But how would the OS know which user to lock? They lock didn’t happen to other users and while I was locked, I could log with another user using the same machine, and even the same browser after removing cookies.
Users in gitlab aren’t linked to pam, so the OS wouldn’t block your account. It was locked in gitlab itself, probably because wakatime was trying to authenticate and had incorrect auth info. Since you stopped using wakatime, and assuming now your account has never got blocked since then, this can be the only reason for it. Gitlab wouldn’t lock the account if correct auth info was provided, so we can only blame wakatime here.
Sorry @mvaled , I never saw your reply until I logged into the website. My apologies.
Anyway, if you were using SSH then your ssh connection would be to the same host where PAM and possible security implementations track how many failed logons and etcetera are accrued (and eventually cleared automatically or by human); which is handled by PAM (i.e. the OS).
But if you are using HTTP/HTTPS then that would be application authentication not OS authentication.
It looks like @iwalker knew something about your environment or situation.
