-
Bug
-
Resolution: Fixed
-
Highest (View bug fix roadmap)
-
None
-
4.1
-
4.01
-
TO CUSTOMERS WHO MAY BE EXPERIENCING THIS ISSUE
This problem is caused because JIRA 4.1 add a new entry into seraph-config.xml.
<elevatedsecurityguard class="com.atlassian.jira.security.login.JiraElevatedSecurityGuard"/>
This line controls the brute force password protection facility.
Customers who simply copy the old seraph-config.xml over the one that ship with JIRA will in effect remove this entry.
People will need to re-add this line in order for the LoginGadget to work as expected.
4.1.2 has new code to ensure that this configuration is checked and messages will be logged and placed into the system info page.
The LoginGadget has also been made less brittle to this missing entry.
However it is essential that this entry be present since it controls the brute force password protection in JIRA 4.1 and you system is less secure without it.
Original Description
Several users in support have reported that when they upgrade to 4.1 that the login gadget stops working. The behavior they see is:
- login.jsp works fine.
- attempting to login via gadget results in the gadget giving a failure message. If you simply refresh the page, however, you have been logged in.
This appears to be a side effect of the changes to add CAPTCHA in 4.1 and the resulting changes to the login gadget. I don't know why Crowd/Seraph are behaving like this but what happens is that:
- a user gets put into the session
- the authstatuskey is success
- the lastLoginResult is null
In 4.0 we just checked if there was a user in the session to declare "login succeeded". Now we look at lastLoginResult, which is null for reasons yet unknown.
WORKAROUND : To any customers affected by this bug, the work around is to use the Login link in the top right corner of the page. This is a link to login.jsp and this is know to work as expected.
- causes
-
-
- Closed
-
[JRASERVER-21205] Login gadget breaks when crowd is enabled
I am trying to fix our jira 4.1.1 instance. We have exactly the above issue and indeed this line is missing from the current seraph-config.xml file (yes it was an upgrade). The CROWD SSO seem to be working (other then this issue. and it is just pretty inconvenient to tell users that refresh !!)
Can someone tell which section (part) of the file this statement needs to be added to??
If adding this line solves problem would be great!!!
Thanks.
Gabor
Gabor Szilagyi
added a comment - - edited I am trying to fix our jira 4.1.1 instance. We have exactly the above issue and indeed this line is missing from the current seraph-config.xml file (yes it was an upgrade). The CROWD SSO seem to be working (other then this issue. and it is just pretty inconvenient to tell users that refresh !!)
Can someone tell which section (part) of the file this statement needs to be added to??
If adding this line solves problem would be great!!!
Thanks.
Gabor 
Giles Gaskell [Atlassian]
added a comment - Hi Chris - yes - that's correct and sorry for the delay in replying. I've added this note to the JIRA 4.1 Upgrade Guide.
Giles Gaskell [Atlassian]
added a comment - Hi Chris - yes - that's correct and sorry for the delay in replying. I've added this note to the JIRA 4.1 Upgrade Guide. 
Brian Topping
added a comment - FWIW, I tried adding <elevatedsecurityguard class="com.atlassian.jira.security.login.JiraElevatedSecurityGuard"/> to my seraph-config.xml and it still displayed all the characteristics of this issue.
Brian Topping
added a comment - FWIW, I tried adding <elevatedsecurityguard class="com.atlassian.jira.security.login.JiraElevatedSecurityGuard"/> to my seraph-config.xml and it still displayed all the characteristics of this issue. I'm confused Giles,
This bug is fixed but there is documentation left to do? That's the way I read the change history, can you confirm?
Giles Gaskell [Atlassian]
added a comment - I've re-opened this issue to remind me to write documentation based on my previous comment soon (to coincide with the release of JIRA 4.1.2). (I've verified this procedure with Oswaldo.)
It'll be closed when this documentation has been published.
Giles Gaskell [Atlassian]
added a comment - I've re-opened this issue to remind me to write documentation based on my previous comment soon (to coincide with the release of JIRA 4.1.2). (I've verified this procedure with Oswaldo.)
It'll be closed when this documentation has been published. We need to add a note about this in the JIRA 4.1 Upgrade Guide, saying that customers who were using Crowd with JIRA 4.0 or earlier will need to conduct step 2 of the Integrating Crowd with Atlassian JIRA page (again), because JIRA's seraph-config.xml file is overridden by the JIRA 4.1 upgrade process.
Furthermore, if they have made any customisations to any of the files mentioned in step 2 prior to the upgrade (for example, the seraph-config.xml file is a perfect candidate), then they should re-integrate these as part of the upgrade process.
Giles Gaskell [Atlassian]
added a comment - - edited We need to add a note about this in the JIRA 4.1 Upgrade Guide , saying that customers who were using Crowd with JIRA 4.0 or earlier will need to conduct step 2 of the Integrating Crowd with Atlassian JIRA page (again), because JIRA's seraph-config.xml file is overridden by the JIRA 4.1 upgrade process.
Furthermore, if they have made any customisations to any of the files mentioned in step 2 prior to the upgrade (for example, the seraph-config.xml file is a perfect candidate), then they should re-integrate these as part of the upgrade process. Resolving this issue and filed JRA-21386 for tracking the CAPTCHA options verification.
Verified with 4.1.2(QA Bamboo build 506), user gets a message in logs which is not noticeable. But there is also reference of same error message in system info and support page which is beneficial. The only issue I can see that if user has this entry missing and he/she enables "CAPTCHA on signup" it will not work.
This is now less brittle in 4.1.2 and we also now log a message if we detect that JiraElevatedSecurityGuard is missing
I have added the above class statement near to the bottom of the file, and then restarted jira. Issue is solved for us.