Strange login error after 2.41.1.0 upgrade

Support - Assistance technique
1

I can’t login and see no errors in the logs on authentification failure

The only thing is this job is failing every x seconds

11:00:15.367 [pool-4-thread-1] ERROR org.hisp.dhis.scheduling.DefaultJobSchedulerLoopService - Job failed: 'AZZA'

org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only

	at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:753) ~[spring-tx-5.3.37.jar:5.3.37]

	at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:712) ~[spring-tx-5.3.37.jar:5.3.37]

	at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:654) ~[spring-tx-5.3.37.jar:5.3.37]

	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:407) ~[spring-tx-5.3.37.jar:5.3.37]

	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119) ~[spring-tx-5.3.37.jar:5.3.37]

	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) ~[spring-aop-5.3.37.jar:5.3.37]

	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:241) ~[spring-aop-5.3.37.jar:5.3.37]

	at jdk.proxy3/jdk.proxy3.$Proxy519.getReport(Unknown Source) ~[?:?]

	at org.hisp.dhis.dataintegrity.jobs.DataIntegrityJob.runReport(DataIntegrityJob.java:80) ~[dhis-service-administration-2.41.1.jar:?]

	at org.hisp.dhis.dataintegrity.jobs.DataIntegrityJob.execute(DataIntegrityJob.java:68) ~[dhis-service-administration-2.41.1.jar:?]

	at org.hisp.dhis.scheduling.JobScheduler.runDueJob(JobScheduler.java:231) ~[dhis-service-core-2.41.1.jar:?]

	at org.hisp.dhis.scheduling.JobScheduler.runContinuous(JobScheduler.java:186) ~[dhis-service-core-2.41.1.jar:?]

	at org.hisp.dhis.scheduling.JobScheduler.lambda$runIfDue$1(JobScheduler.java:173) ~[dhis-service-core-2.41.1.jar:?]

	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]

	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]

	at java.base/java.lang.Thread.run(Thread.java:840) [?:?]

11:00:15.368 [pool-4-thread-1] ERROR org.hisp.dhis.scheduling.DefaultJobSchedulerLoopService - org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only

	at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:753)

	at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:712)

	at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:654)

	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:407)

	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)

	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)

	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:241)

	at jdk.proxy3/jdk.proxy3.$Proxy519.getReport(Unknown Source)

	at org.hisp.dhis.dataintegrity.jobs.DataIntegrityJob.runReport(DataIntegrityJob.java:80)

	at org.hisp.dhis.dataintegrity.jobs.DataIntegrityJob.execute(DataIntegrityJob.java:68)

	at org.hisp.dhis.scheduling.JobScheduler.runDueJob(JobScheduler.java:231)

	at org.hisp.dhis.scheduling.JobScheduler.runContinuous(JobScheduler.java:186)

	at org.hisp.dhis.scheduling.JobScheduler.lambda$runIfDue$1(JobScheduler.java:173)

	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)

	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)

	at java.base/java.lang.Thread.run(Thread.java:840)

in the meantime I discovered that

   curl -u 'user:password'  https://mydhis2/api/organisationUnits

works

it’s really the login that seem broken
api/41/auth/login
and returns
{"httpStatus":"Unauthorized","httpStatusCode":401,"status":"ERROR","message":"Bad credentials"}
with the good credentials.

is there a new settings in dhis2.conf ?

2

Hi @Stephan_Mestach

Thank you for your post. Are you able to login using the old login page? https://mydhis2/dhis-web-commons/security/login.action

Could you check if this is the same issue you are facing: fix: login fails when there is attribute values assigned to the user by netroms · Pull Request #18591 · dhis2/dhis2-core · GitHub? Hopefully this is the fix to the issue.

cc: @nnkogift @netroms @tzemp

3

That’s working, it’s really strange.

  • For your info the password contains special chars =#. and letter lower and uppercase/numbers
  • There’s a space in the username User Name
  • The password looked “old” (2019) according to passwordLastUpdated
  • I know that there’s F5 router/firewall in between but don’t know if a rule could affect the new login page
  • I haven’t found an attribute in /api/attributes?fields=:all&filter=userAttribute:eq:true

What is really annoying is I don’t have logs. What is the expected way to configure them ?
On older version, I managed to have log4j.properties to work

4

@Gassim I noticed on play that creating user with spaces is no more allowed

https://play.im.dhis2.org/stable-2-41-1/dhis-web-user/index.html#/users/new

image

is it possible that this new constraints block the new login page?

So I can confirm the blanks are the problem.
We fixed

update userinfo set username = 'User_Name' where uid= 'viBdNlLjzzv';

restarted the server
then managed to login with the new and the old page.

We have 60 users with blanks

select username from userinfo where username like '% %' ;

Do you plan to migrate every user or remove that “constraint” in the api/41/auth/login enpoint ?

Can you share an sql script to find all the bad usernames ? What is the regexp used ? I guess the problem arrived with 41.x versions (and the new login page) ?

Same problem with accent : Stéphan or Élie were allowed before, not anymore in 41.x

1 Like
5

Can you confirm ? will you prepare a fix ? @nnkogift @netroms @tzemp

6

from my small tests

  • older version 2.28… 2.37 don’t have that constraint
  • 2.39.5 and upper have the constraints but login is ok
  • 2.41 login start assuming that the username should match the constraint about blanks and special chars.

I haven’t found a migration fixing existing username to match that constraints

7

Thank you very much @Stephan_Mestach for looking into that. I think we need to discuss a little bit as a team and think about what the approach should be with regards to historic user names that no longer meet the current username restrictions. We’ll try to discuss that next week and then get back to you.

The easiest workaround, as you’ve already suggested is to update the usernames that violate the current restrictions*

* 4-255 characters, where valid characters are: A-z, 0-9, -, _, ., and @

1 Like
8

yes but communicating to a lot of users that their username has changed is a nightmare… and hopping we won’t have conflicts while “fixing” their username.

note that the api with basic auth and old login page still accept them.

I would have expected something sooner, we didn’t identified the problem during our test (since the user didn’t had blanks) and now this has been rolled out.

1 Like
9

Does something has been decided ? (I’m secretly hoping it will relaxed)

1 Like
10

Thanks @Stephan_Mestach ! The @dhis2-platform team are discussing the issue. We’ll post back when there is an update. Thank you for following up and sharing all the details.

In the mean time, how are you managing in the production instance? Thank you!

11

Thank you again @Stephan_Mestach. We’ve identified the cause of the problem and will work to implement a fix. You can follow our work on the related Jira issue: DHIS2-18096.

Because this fix requires an update to the core DHIS2 code, it will need to be fixed with an upcoming 2.41 release. We hope to have this fixed in the next release, but we do not currently have a definite date for that.

We apologize for the inconvenience here and thank you again for reporting the issue. If it is not possible to use the workaround (updating usernames and communicating that to users), you could also consider rolling back your instance for the time being.

1 Like
12

In the meantime, we’ve put the url of the old login page in the “new” page with a comment.

2 Likes
13

In the meantime, we’ve put the url of the old login page in the “new” page with a comment.

Glad that you found a workaround for the problem @Stephan_Mestach.

The issue has now been fixed and the update will be included in the next release of v41.

Thank you again for reporting and sorry for the troubles.

1 Like