-
Bug
-
Resolution: Fixed
-
Highest
-
None
-
8.22.0, 8.20.8
-
8.2
-
9
-
Severity 3 - Minor
-
13
-
Issue Summary
This is reproducible on Data Center: yes
Steps to Reproduce
- Install any plugin with custom Seraph authenticator implementation(More on custom authentication in Jira here, example here)
- Set up your Jira to use the plugin's authenticator
- Remove user "x" from user cache on nodeN
- Log in as user "x" on nodeN
Expected Results
User is able to login and work with Jira in without any errors
Actual Results
Login process fails and the below error messages can be seen in the xxxxxxx.log file:
User does not exist and cannot be created. Creation is disabled for all the users. Authentication failed.
Workaround
(Taken from https://jira.atlassian.com/browse/JRASERVER-71483 )
- Refresh caches by full Jira restart (very painful and requires an outage):
- Full restart in Data Center is required because nodes with a corrupted cache will replicate it to other starting nodes, this means shutting down all nodes, validating the service is stopped, and starting them back up, a rolling restart will not resolve this issue.
- Add new directory, then remove it:
- Create a brand new User Directory - this directory does not necessarily actually have to work
- Delete the newly created directory. This will trigger the user and group caches to be invalidated.
- Synchronize the existing User Directory
- When using SAML Single Sign On plugin and remote directory:
- Enable the option to fetch users from remote directory. It should refresh user cache on every successful log in.
- is related to
-
JRASERVER-70690 User login fails because inconsistent data / uk_mem_parent_child_type
- Closed
- relates to
-
JRASERVER-71483 As a Jira admin I would like to recover from user cache corruption without a whole cluster restart
- Closed
-
LOGIN-91 Loading...
-
LOGIN-94 Loading...
- was cloned as
-
JRASERVER-74246 Instances using CROWD as SSO provider might fail to log in users due to corrupt cache
- Closed
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...