Re: TokenInterceptor locking HTTP session for entire action invocation?

2015-07-13 Thread Lukasz Lenart
2015-07-10 20:37 GMT+02:00 rgm str...@rgm.nu:
 Using Struts 2.3.20.1.

 We have a long-running token-protected (for CSRF) action that can take up
 to about 30 seconds sometimes.  When this action is running on behalf of
 Alice, the List Users page for all other people on the system such as
 Bob and Charlie is hung, because the List Users page is trying to show
 whether or not Alice is logged in by accessing properties of her HTTP
 session.

 Is it necessary for TokenInterceptor to hold onto the session lock for the
 entire action invocation?

It is. It's the only way to be sure that we do not have duplicated
submits for the same token


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org



Re: TokenInterceptor locking HTTP session for entire action invocation?

2015-07-13 Thread Lukasz Lenart
Hmm looks interesting :) There is issue opened for 2.3.x so could
you post your comment there as well? I will try to investigate how to
use Striped (maybe not directly) with Token interceptor

https://issues.apache.org/jira/browse/WW-4409


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2015-07-14 1:52 GMT+02:00 Ken McWilliams ken.mcwilli...@gmail.com:
 Could a Striped lock not be used? If done, machinery would need to be
 introduced which would quickly go beyond s2's prerogative. For instance an
 interceptor could have this magic locking service injected and then say:
 For User X, is token Y in use? Or for any user is token Y in use? But then
 this brings up user management, which is outside of S2 and then security
 quickly follows...

 So keeping is simple, S2 offers a reasonable solution but I think you could
 develop a more narrow locking scheme that locks on the value of the token
 stored in a Striped lock:
 http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/Striped.html




 On Mon, Jul 13, 2015 at 5:26 AM, Lukasz Lenart lukaszlen...@apache.org
 wrote:

 2015-07-10 20:37 GMT+02:00 rgm str...@rgm.nu:
  Using Struts 2.3.20.1.
 
  We have a long-running token-protected (for CSRF) action that can take up
  to about 30 seconds sometimes.  When this action is running on behalf of
  Alice, the List Users page for all other people on the system such as
  Bob and Charlie is hung, because the List Users page is trying to show
  whether or not Alice is logged in by accessing properties of her HTTP
  session.
 
  Is it necessary for TokenInterceptor to hold onto the session lock for
 the
  entire action invocation?

 It is. It's the only way to be sure that we do not have duplicated
 submits for the same token


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 -
 To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
 For additional commands, e-mail: user-h...@struts.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org



Re: TokenInterceptor locking HTTP session for entire action invocation?

2015-07-13 Thread Ken McWilliams
Could a Striped lock not be used? If done, machinery would need to be
introduced which would quickly go beyond s2's prerogative. For instance an
interceptor could have this magic locking service injected and then say:
For User X, is token Y in use? Or for any user is token Y in use? But then
this brings up user management, which is outside of S2 and then security
quickly follows...

So keeping is simple, S2 offers a reasonable solution but I think you could
develop a more narrow locking scheme that locks on the value of the token
stored in a Striped lock:
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/Striped.html




On Mon, Jul 13, 2015 at 5:26 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 2015-07-10 20:37 GMT+02:00 rgm str...@rgm.nu:
  Using Struts 2.3.20.1.
 
  We have a long-running token-protected (for CSRF) action that can take up
  to about 30 seconds sometimes.  When this action is running on behalf of
  Alice, the List Users page for all other people on the system such as
  Bob and Charlie is hung, because the List Users page is trying to show
  whether or not Alice is logged in by accessing properties of her HTTP
  session.
 
  Is it necessary for TokenInterceptor to hold onto the session lock for
 the
  entire action invocation?

 It is. It's the only way to be sure that we do not have duplicated
 submits for the same token


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 -
 To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
 For additional commands, e-mail: user-h...@struts.apache.org




TokenInterceptor locking HTTP session for entire action invocation?

2015-07-11 Thread rgm
Using Struts 2.3.20.1.

We have a long-running token-protected (for CSRF) action that can take up
to about 30 seconds sometimes.  When this action is running on behalf of
Alice, the List Users page for all other people on the system such as
Bob and Charlie is hung, because the List Users page is trying to show
whether or not Alice is logged in by accessing properties of her HTTP
session.

Is it necessary for TokenInterceptor to hold onto the session lock for the
entire action invocation?

Sincerely,

rgm


TokenInterceptor locking HTTP session for entire action invocation?

2015-07-10 Thread rgm
Using Struts 2.3.20.1.

We have a long-running token-protected (for CSRF) action that can take up
to about 30 seconds sometimes.  When this action is running on behalf of
Alice, the List Users page for all other people on the system such as
Bob and Charlie is hung, because the List Users page is trying to show
whether or not Alice is logged in by accessing properties of her HTTP
session.

Is it necessary for TokenInterceptor to hold onto the session lock for the
entire action invocation?

Sincerely,

rgm