Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Cannot write login token error after installing 5.6.1 SP 2

Avatar

Level 2

Hi Everyone.

I've installed 5.6.1 SP 2 on a couple of test publish nodes and I get the following error when I try to authenticate via LDAP:

24.08.2015 16:51:57.705 *ERROR* [0:0:0:0:0:0:0:1 [1440449516586] POST /etc/login.html/j_security_check HTTP/1.1] [<our custom LDAP login module class name>] commit: could not commit: javax.jcr.RepositoryException: Cannot create login token.

The exception originates in org.apache.jackrabbit.core.security.authentication.tokenTokenBasedAuthentication.createToken. I set the logging level to TRACE to see if I could get more info, but nothing useful stood out.

It looks like the LDAP authentication part is successful. I can see that the user node gets created under /home/users/<path to user node> along with some custom properties we write. The .tokens node, however, does not get created. This is consistent with the message in the RepositoryException.

Our LDAP module has been working for a long time. This error only occurs after I install SP 2. I've confirmed this on multiple publish nodes. If I revert to the backup prior to SP 2, I can login just fine.

I can see com.day.crx.sling.server is running at 2.4.76 and all bundles are active. Our custom LDAP login module bundle is Fragment. So it seems SP 2 has installed. I can login to the web console, crx explorer / de, etc. So the system seems to be functioning for the most part.

Any ideas on what might be causing my login token problem? Has anyone else had a similar problem? Thanks.

1 Accepted Solution

Avatar

Correct answer by
Level 2

I figured out the problem. SP 2 upgrades the Apache Jackrabbit API bundle from 2.6.2 to 2.7.5. Jackrabbit handles tokens differently in 2.7.5. TokenBasedAuthentication.java changed significantly, but has the old token code for backwards compatibility.

2.6.2 version of TokenBasedAuthentication.java

2.7.5 version of TokenBasedAuthentication.java

After reviewing the code changes, I added the following JVM system property to our CQ startup script: -DTokenCompatMode=true

Once I restarted, login started working again.

So if you upgrade to SP 2 and run into trouble with your custom LDAP authentication module, with errors like this:

Caused by: javax.jcr.RepositoryException: Cannot create login token. at org.apache.jackrabbit.core.security.authentication.token.TokenBasedAuthentication.createToken(TokenBasedAuthentication.java:189)

then you might need to set TokenCompatMode.

View solution in original post

5 Replies

Avatar

Level 10
  1. Go to /system/console/topology and capture ClusterView id value
  2. Stop AEM
  3. Edit cluster.properties file setting cluster_id to the value captured in step #1
  4. Restart AEM

Let me know how it goes after this. 

Avatar

Correct answer by
Level 2

I figured out the problem. SP 2 upgrades the Apache Jackrabbit API bundle from 2.6.2 to 2.7.5. Jackrabbit handles tokens differently in 2.7.5. TokenBasedAuthentication.java changed significantly, but has the old token code for backwards compatibility.

2.6.2 version of TokenBasedAuthentication.java

2.7.5 version of TokenBasedAuthentication.java

After reviewing the code changes, I added the following JVM system property to our CQ startup script: -DTokenCompatMode=true

Once I restarted, login started working again.

So if you upgrade to SP 2 and run into trouble with your custom LDAP authentication module, with errors like this:

Caused by: javax.jcr.RepositoryException: Cannot create login token. at org.apache.jackrabbit.core.security.authentication.token.TokenBasedAuthentication.createToken(TokenBasedAuthentication.java:189)

then you might need to set TokenCompatMode.

Avatar

Level 2

Thanks for responding. I followed your suggestion and nothing changed.

I also shutdown, deleted the system.id and sling.id.file files, manually set the values in cluster_node.id and cluster.properties. Didn't change the behavior either.

Avatar

Level 10

Thanks Rob. Please file an support ticket for further deep investigation & fix.