Sounds good - feel free to ask any questions and we'll help out as best as we can (given time restrictions due to work, etc).
Cheers, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Sat, May 4, 2013 at 1:30 PM, Laszlo Ferenczi <[email protected]> wrote: > Hi Les, > > Sure, no problem. (assuming i can register to use jira) > > For the patch - actually tried it. The thing is that I only use shiro for a > week and I don't really feel very confident to touch it. Still a lot to > digest. > > -- > L > > > -- > L > > > On Saturday, May 4, 2013 at 9:32 PM, Les Hazlewood wrote: > >> Hi Laszlo, >> >> Could you please open a Jira issue for this? It will be lost unless >> captured in Jira. Also, if possible, could you please provide a patch >> for this fix? (patches usually help us fix things faster). >> >> Thanks, >> >> -- >> Les Hazlewood | @lhazlewood >> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 >> >> On Thu, May 2, 2013 at 4:53 AM, Laszlo Ferenczi <[email protected] >> (mailto:[email protected])> wrote: >> > Hi, >> > >> > While integrating Shiro to our guice based webapp I've noticed >> > something strange. The module setup is pretty much the same as the >> > example in the Guice page of Shiro's documentation. Only extra code is >> > that I'm exposing the WebSecurityManager like this: >> > >> > public class AuthModule extends ShiroWebModule { >> > >> > public AuthModule(ServletContext servletContext) { >> > super(servletContext); >> > } >> > >> > @Override >> > @SuppressWarnings("unchecked") >> > protected void configureShiroWeb() { >> > IniRealm iniRealm = new >> > IniRealm(Ini.fromResourcePath("classpath:shiro.ini")); >> > bindRealm().toInstance(iniRealm); >> > expose(WebSecurityManager.class); >> > } >> > } >> > >> > A guice injected SecurityManager instance is not the same as the >> > cached static SecurityManager in SecurityUtils. >> > >> > @Path("/Ping") >> > @Singleton >> > public class PingResource { >> > @Inject >> > SecurityManager sec; >> > >> > @Inject >> > WebSecurityManager websec; >> > >> > @GET >> > public void ping() { >> > SecurityManager man = SecurityUtils.getSecurityManager(); >> > >> > assert(man == websec); >> > assert(man == sec); >> > } >> > } >> > >> > First assert passes, second fails. Debugger confirms that there are 2 >> > instances in memory, both of them are of type >> > DefaultWebSecurityManager but only the WebSecurityManager instance >> > works. Any meaningful operation on "sec" will fail (like an >> > authorization check). >> > >> > I think the problem might be the double binding of SecurityManager(s). >> > One is bound in ShiroModule another is in ShiroWebModule: >> > >> > in ShiroModule: >> > >> > public void configure() { >> > // setup security manager >> > bindSecurityManager(bind(SecurityManager.class)); >> > >> > in ShiroWebModule: >> > >> > protected final void configureShiro() { >> > .... >> > bindWebSecurityManager(bind(WebSecurityManager.class)); >> > >> > Both of these methods are running at init time, hence the duplicated >> > singletons. >> > >> > It might be better if ShiroWebModule would overrinde the standard >> > configure() method to avoid this double-binding. >> > Is it possible to get a fix for this please ? >> > >> > Thanks in advance ! >> > >> > Best regards, >> > Laszlo >> > > >
