>Shiro's filters can filter remote invocations only: > >1) You use an HTTP-based remoting >2) Whatever client mechanism you use to execute the remote invocation >sets the session ID as a cookie in the request header. > >#2 is _not_ done automatically for you by the client >SecureRemoteInvocationFactory (SRIF). The SRIF does not know about >transport protocol, so it has no way of setting a cookie (protocol >specific function).
Oh! now I see... I should understand it before but I did not... >So the only way, out of the box, to use the filters for http-based >remoting is to ensure that you're using a remoting mechanism that >supports cookies. > >This would work if you used the Jakarta Commons HttpClient as the >Spring HTTP remoting executor. The only other requirement is that you >have to start a session or log in with the client application first so >that the HttpClient could remember the session ID cookie resulting >from the login. Ok. I'll try to use Jakarta Commons HttpClient to check how it works. >How does your application's authentication work? Do you log in via a >web page and then launch the desktop application (e.g. Java Webstart >or Adobe Air)? Or does the application start first and the user >authenticates via the desktop application? Desktop application starts, user sends login/password(spring remoting) and gets sessionID. then on client I build new Shiro session with this sessionId . With Shiro session I build new Subject. and with Subject I use "subject.execute" method to call my secure beans under filter. Is it right method to work? After all as I understand adding perms[remote:invoke] makes it bypass filter and call spring bean. It means that with perms[remote:invoke] all beans are open to everyone. With perms[remote:invoke] filter does not check if you logged in or not. am I right? my problem is: I want that all remote beans by default will be closed to every one. with your help I see two way to solve my problem add cookie to http request for example with Jakarta Commons HttpClient(fix on filter level) or customize org.apache.shiro.spring.remoting.SecureRemoteInvocationExecutor on server side(fix after filter but before bean invocation). am I right ? -- View this message in context: http://n2.nabble.com/Adding-new-custom-filter-to-filters-in-ShiroFilter-tp4188224p4205698.html Sent from the Shiro User mailing list archive at Nabble.com.
