[ 
https://issues.apache.org/jira/browse/ISIS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620794#comment-14620794
 ] 

ASF subversion and git services commented on ISIS-1169:
-------------------------------------------------------

Commit edc4fa7648f73dea2c3be41de24b29ca76af9fe4 in isis's branch 
refs/heads/master from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=edc4fa7 ]

ISIS-1169: change to (try to) avoid "session already open" error 
(http://isis.markmail.org/thread/2dn7tja3r466yd2m)

- IsisContextThreadLocal now uses AUTO_CLOSE session policy instead of 
EXPLICIT_CLOSE session policy
- simplified IsisSessionFilter:
  - always call closeSession() in a finally block
  - get rid of SessionState enum, since never used
- enhanced IsisTransactionFilterForRestfulObjects to be resilient of the fact 
that the session/transaction may no longer exist (if the authSession is closed 
by a resource)
- added user/logout resource to UserResourceServerSide, enhanced 
UserReprRenderer to display new link (plus new proprietary Rel for this)
- extended IsisSessionFilter, also AuthenticationSessionStrategy interface
  - special query string to set on redirect to request that the session be 
closed
  - new AuthenticationSessionStrategy#invalidate(), called on this
   - default impl returns 401, UNAUTHORIZED... this is enough to effect a 
server-side "logout" for BASIC auth
- updated IsisSession#close() so that if takeSnapshot() throws exception, then 
this doesn't prevent the persistence session from being closed
- updated PersistenceSession#close(), better debugging if the 
objectStore#close() or the adapterManager#close() were to throw an exception.
- removed unused DeploymentType#UTILITY instance.


> Simplify IsisSessionFilter, make more resilient to possible leakage of 
> IsisSession on thread-local, also allow RO to force a logout
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ISIS-1169
>                 URL: https://issues.apache.org/jira/browse/ISIS-1169
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: core-1.8.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: 1.9.0
>
>
> This ticket has been prompted by a report from Nacho [1] about a session 
> being left open.   Note that Nacho's app (working with Oscar Bou) doesn't use 
> the wicket viewer, instead they have their own proprietary viewer based on 
> Wavemaker.
> Even so, for normal operation the IsisSessionFilter is used for the Restful 
> Objects API, so this issue could arise more widely.
> Nacho suggested a possible small improvement, though he reported that didn't 
> completely fix the issue.  Looking into the code in more detail, it would 
> seem that the issue can arise if the closeSession() is not called somehow, 
> perhaps from an NPE or other RuntimeException being thrown.
> Also looking at IsisSessionFilter, it seems that this code is more complex 
> than required; the SessionState enum only ever takes the value of UNDEFINED.  
> So this can be simplified.
> At the same time (mostly for testing this but also since it is overdue) this 
> seems like a good opportunity to introduce the ability to "logout" of RO.  
> After some experimentation, have decided to implement by introducing a new 
> non-standard /user/logout resource to RO, and using redirect and a special 
> query string to tell the IsisSessionFilter to respond with a 401.  It doesn't 
> seem to be possible to do better than this for a pure server-side solution 
> (see eg [2])
> I've also decided - belt and braces - to get rid of the fail-fast 
> EXPLICIT_CLOSE policy for SessionClosePolicy and instead always use 
> AUTO_CLOSE.  That way if - for some reason - the session is left open on a 
> thread, then it will be automatically closed the next time that thread is 
> reused.  If my above refactoring is ok then this should never happen, but I'm 
> taking the view that I'd rather the code is resilient to a bug elsewhere (and 
> live with a bit of memory leakage) than to blow up (as it currently does).
> [1] http://isis.markmail.org/thread/2dn7tja3r466yd2m
> [2] 
> http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to