Expand my Community achievements bar.

SOLVED

Getting CQ5.6 authentication details in a custom auth handler

Avatar

Level 5

We have a custom authentication handler. But we want to check if the user is logged into CQ5 for example if they are on the author. I know we could just do an isAuthor check but we want to be able to see which user it is who is signed in. The custom auth is only used on certain parts of the site and grants access depending on info obtained from the commerce aspect of our site but we also want to check who the cq5 user is if anybody. When I say CQ5 user I'm referring to the user who would log in when accessing the author for example on the AEM splash page when first hitting the author url. I have spend quite a bit of time getting no where with this, from what I can see the authentication info is contatinred in a cookie called login-token but I can't work out how to 'decode' that to get the user name and validate the password is correct. Hope this makes sense. (This is on a 5.6 implementation of CQ5).

1 Accepted Solution

Avatar

Correct answer by
Employee

Sutty-

Does ResourceResolver.getUserID() / Session.getUserID() do what you are looking for? Your question doesn't really make sense to me as the outcome of creating a custom AuthenticationHandler is that your AuthenticationHandler decides what user is logged in. Your question makes it sound like you expect there to be two different userIDs, but there really should just be one.

Regards,

Justin

View solution in original post

4 Replies

Avatar

Level 10

CQ exposes this Java Interface:

https://dev.day.com/docs/en/cq/current/javadoc/org/apache/sling/auth/core/spi/AuthenticationHandler....

I am looking to see if we have any content that discusses how to work with this Java interface to perform authentication tasks. 

I will post any updates. 

Avatar

Correct answer by
Employee

Sutty-

Does ResourceResolver.getUserID() / Session.getUserID() do what you are looking for? Your question doesn't really make sense to me as the outcome of creating a custom AuthenticationHandler is that your AuthenticationHandler decides what user is logged in. Your question makes it sound like you expect there to be two different userIDs, but there really should just be one.

Regards,

Justin

Avatar

Level 5

Justin,

No HttpServletRequest.getSession does not have a getUserId method. 

The reason we need to do this because we use a third party commerce system, that handles all log on functions. We use the custom auth for certain areas of the site where you need to have special permissions to view. So We check with the commerce system if the user has permission to view the page if yes great if not then dont show. However if the user is on the author then there is no third party commerce system and they sign in using the standard cq5 authentication. So what I want to do is get that authentication and return it from the custom auth. I have tried returning null hoping that it bubbles up to the default authentication handler but unfortunately it doesn't. I realise I could do an isAuthor check but I want to find a way of getting the cq5 user especially because we will be moving to using cq5 for handling authorisation. 

So in essence my question is how can I from a class get the current users CQ5 authentication info and/or signal that the custom authentication wants the default cq5 authentication to take over and perform the authentication.

Thanks

Tom 

Avatar

Employee

I was refererring to javax.jcr.Session. See http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Session.html#getUserID().

But mostly you shouldn't be handling authorization in this. JCR has built-in authorization, so you do not need to implement the logic to handle "if the user has permissions ot view the page...if not then don't show."

If you need custom authentication, write an AuthenticationHandler (and returning null definitely work as a return value of the extractCredentials() method). But assuming you authorization needs are met by the privledges already handled by the repository, there's no need to reinvent that wheel.