I didn’t even think about request scoped things. But yeah, it should be
fine. Something like:
@Provides @RequestScoped
Subject provideSubject() {
return SecurityUtils.getSubject();
}
As far as the filter - I'm really not sure.
On Sat, Oct 19, 2013 at 6:08 PM, Josh Berry <[email protected]> wrote:
> On Sat, Oct 19, 2013 at 5:01 PM, Jared Bunting <
> [email protected]> wrote:
>
>> There's not really anything built-in to do this, but there are things
>> that you can do. The object that you're going to want to inject is Subject
>> - you can access the session through that.
>>
>
> Awesome, thanks. I had actually meant to say Subject instead of user.
> Not sure why I did that typo.
>
>
>> My recommendation would be to use a @Provides method on your Shiro module
>> to return the result of SecurityUtils.getSubject(). I would recommend
>> injecting Provider<Subject>. If you really want to inject a native Subject
>> (rather than the provider), then I would write an implementation of Subject
>> that just always calls SecurityUtils.getSubject() and delegates to the
>> result of that call. Of course, it would need to throw an exception if
>> there is no current subject.
>>
>
> If I'm going to be injecting this into only request scoped things, is
> there a real difference between the provider and just directly injecting
> the Subject?
>
> Also, I encountered some annoyance dealing the the Guice JPA extension and
> Shiro. Specifically, the PersistFilter is not "reentrant" (I think that is
> the right term) and would throw an exception on forwarded requests. I
> basically used your OncePerRequest pattern to wrap the PersistFilter. Does
> this sound like I did something else wrong, or would this be expected with
> any other filter in the application? (If it helps, I can probably setup a
> minimal example of what I'm talking about on github.)
>
> Again, thanks!
>
> -josh
>
