[Authentication] option to close session passed as "user.jcr.session"

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Authentication] option to close session passed as "user.jcr.session"

Alexander Klimetschek-2
Hi,

one of the options in a Sling Authentication handler is to create the session itself and pass it via "user.jcr.session" [1] in the AuthenticationInfo. But this session is never closed automatically by Sling, forcing you to also write yet-another ServletFilter that closes the session at the end of the request, which is ugly.

So I am proposing a new option "user.jcr.session.close" that one can set which would close the session. The change would be simple: in [2] set logoutSession = true if this flag is present. IMO closing by default would make more sense, not sure if we can do that...

WDYT?

Background:

Passing an existing session is the most generic way to login for an auth handler, but due to the non-auto-closing, it's impractical.

Also, this is my current requirement, you can use Jackrabbit's TokenCredentials and verify attributes - these are added back to the credentials objects _after_ the login, which happens _after_ the authentication handler and all authentication post processors, so no chance for me to do some validation on them inside the auth handler. Unless I want to create an extra throw-away session just for the check - which is a waste to do for every single request.

[1] https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceConstants.java#L107
[2] https://github.com/apache/sling/blob/5b48c807c29241324a11b0056d0d10f4609780a1/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java#L337

Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: [Authentication] option to close session passed as "user.jcr.session"

Antonio Sanso
hi Alex,

is there any JIRA issue I can watch ?

regards

antonio
On Jan 10, 2015, at 3:54 AM, Alexander Klimetschek <[hidden email]> wrote:

> Hi,
>
> one of the options in a Sling Authentication handler is to create the session itself and pass it via "user.jcr.session" [1] in the AuthenticationInfo. But this session is never closed automatically by Sling, forcing you to also write yet-another ServletFilter that closes the session at the end of the request, which is ugly.
>
> So I am proposing a new option "user.jcr.session.close" that one can set which would close the session. The change would be simple: in [2] set logoutSession = true if this flag is present. IMO closing by default would make more sense, not sure if we can do that...
>
> WDYT?
>
> Background:
>
> Passing an existing session is the most generic way to login for an auth handler, but due to the non-auto-closing, it's impractical.
>
> Also, this is my current requirement, you can use Jackrabbit's TokenCredentials and verify attributes - these are added back to the credentials objects _after_ the login, which happens _after_ the authentication handler and all authentication post processors, so no chance for me to do some validation on them inside the auth handler. Unless I want to create an extra throw-away session just for the check - which is a waste to do for every single request.
>
> [1] https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceConstants.java#L107
> [2] https://github.com/apache/sling/blob/5b48c807c29241324a11b0056d0d10f4609780a1/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java#L337
>
> Cheers,
> Alex

Reply | Threaded
Open this post in threaded view
|

Re: [Authentication] option to close session passed as "user.jcr.session"

Felix Meschberger-3
In reply to this post by Alexander Klimetschek-2
Hi

IIRC we have been discussing that before … Not sure what the resolution was and I actually was under impression we agreed to do it. Maybe it just fell off the trenches.

Yes, I think a new constant

> JcrResourceContstants.AUTHENTICATION_INFO_SESSION_LOGOUT = „user.jcr.session.logout“;

Sounds reasonable. Type would be boolean (using PropertiesUtil.toBoolean) with a default value of false:

> logoutSession = PropertiesUtil.toBoolean(
>       authenticationInfo.get(
>            AuthInfoPostProcessor.AUTHENTICATION_INFO_SESSION_LOGOUT),
>            false
>       )
>    );

WDYT ?

Regards
Felix

> Am 10.01.2015 um 03:54 schrieb Alexander Klimetschek <[hidden email]>:
>
> Hi,
>
> one of the options in a Sling Authentication handler is to create the session itself and pass it via "user.jcr.session" [1] in the AuthenticationInfo. But this session is never closed automatically by Sling, forcing you to also write yet-another ServletFilter that closes the session at the end of the request, which is ugly.
>
> So I am proposing a new option "user.jcr.session.close" that one can set which would close the session. The change would be simple: in [2] set logoutSession = true if this flag is present. IMO closing by default would make more sense, not sure if we can do that...
>
> WDYT?
>
> Background:
>
> Passing an existing session is the most generic way to login for an auth handler, but due to the non-auto-closing, it's impractical.
>
> Also, this is my current requirement, you can use Jackrabbit's TokenCredentials and verify attributes - these are added back to the credentials objects _after_ the login, which happens _after_ the authentication handler and all authentication post processors, so no chance for me to do some validation on them inside the auth handler. Unless I want to create an extra throw-away session just for the check - which is a waste to do for every single request.
>
> [1] https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceConstants.java#L107
> [2] https://github.com/apache/sling/blob/5b48c807c29241324a11b0056d0d10f4609780a1/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java#L337
>
> Cheers,
> Alex

Reply | Threaded
Open this post in threaded view
|

Re: [Authentication] option to close session passed as "user.jcr.session"

Alexander Klimetschek-2
On 12.01.2015, at 02:53, Felix Meschberger <[hidden email]> wrote:

>
> IIRC we have been discussing that before … Not sure what the resolution was and I actually was under impression we agreed to do it. Maybe it just fell off the trenches.
>
> Yes, I think a new constant
>
>> JcrResourceContstants.AUTHENTICATION_INFO_SESSION_LOGOUT = „user.jcr.session.logout“;
>
> Sounds reasonable. Type would be boolean (using PropertiesUtil.toBoolean) with a default value of false:
>
>> logoutSession = PropertiesUtil.toBoolean(
>>      authenticationInfo.get(
>>           AuthInfoPostProcessor.AUTHENTICATION_INFO_SESSION_LOGOUT),
>>           false
>>      )
>>   );
>
> WDYT ?

Ack, sounds good. I created https://issues.apache.org/jira/browse/SLING-4301

Cheers,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: [Authentication] option to close session passed as "user.jcr.session"

Alexander Klimetschek-2
On 12.01.2015, at 14:53, Alexander Klimetschek <[hidden email]> wrote:
> Ack, sounds good. I created https://issues.apache.org/jira/browse/SLING-4301

I attached a patch.

But while testing it, I had a problem, see https://issues.apache.org/jira/browse/SLING-4301?focusedCommentId=14276415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14276415

We currently have to use HttpServlets directly registered with the osgi HttpService (since we need to handle wildcard paths), i.e. not sling servlets, but we reuse the sling authenticator in handleSecurity.

This works fine with other, normal ways of logging in to the JCR using e.g. jackrabbit tokens, this problem only comes up with the user.jcr.session + logout approach.

Any ideas?

Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: [Authentication] option to close session passed as "user.jcr.session"

Felix Meschberger-3
Hi

> Am 14.01.2015 um 04:01 schrieb Alexander Klimetschek <[hidden email]>:
>
> On 12.01.2015, at 14:53, Alexander Klimetschek <[hidden email]> wrote:
>> Ack, sounds good. I created https://issues.apache.org/jira/browse/SLING-4301
>
> I attached a patch.
>
> But while testing it, I had a problem, see https://issues.apache.org/jira/browse/SLING-4301?focusedCommentId=14276415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14276415
>
> We currently have to use HttpServlets directly registered with the osgi HttpService (since we need to handle wildcard paths), i.e. not sling servlets, but we reuse the sling authenticator in handleSecurity.
>
> This works fine with other, normal ways of logging in to the JCR using e.g. jackrabbit tokens, this problem only comes up with the user.jcr.session + logout approach.
>
> Any ideas?

The SlingAuthenticator.requestDestroyed method is called *after* the service method has been called and completed. I cannot reproduce your problem. Would you be able to provide some sample code which exhibits this issue ? Thanks.

See als my comments in the issue.

Regards
Felix

>
> Cheers,
> Alex