Re: TokenInterceptor locking HTTP session for entire action invocation?
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?
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?
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
