Hi David (CC: shiro-dev for archival), There is a WebUtils binding bug I accidentally introduced over the weekend. I _just_ committed a quick fix that will hopefully make that work until the SubjectBuilder API is flushed out. Kalle, if you're reading this, try an SVN update and see if it works for you too.
An SVN up should help get past the WebUtils issues for now... Cheers, Les On Mon, Aug 24, 2009 at 2:15 PM, David Higginbotham<[email protected]> wrote: > I think I can find some time to test your changes, although probably not > completely. I was kind of hoping I could at least successfully use the > getSubjectSessionId method at this point, and then refactor based on your new > process at a later point. But if you think you'll have something stable in a > week I can wait. > > GWT handles session info through a RemoteServlet class (which I think extends > the HTTPServlet class). Im not sure I have the name correct. We use this > class with our remote procedure calls and pass the 'UserToken', which > contains the session Id, through every rpc call. The server side then needs > the ability to get the user associated with the session Id. > > I updated from the repository this morning and tried to run my software with > the new jar. I was getting a WebUtils.bind error. I did not change anything > in my Shiro filter, which I put together from Bruce's tutorials. Any ideas > what I need to change to sync up my code ? I've been working from a jar I > built from the repository about 2 weeks ago. > > > > > ----- Original Message ---- > From: Les Hazlewood <[email protected]> > To: David Higginbotham <[email protected]> > Sent: Monday, August 24, 2009 12:48:30 PM > Subject: Re: Shiro - getSubjectBySessionId > > Hi David, > > On Mon, Aug 24, 2009 at 10:27 AM, David Higginbotham<[email protected]> wrote: >> Hi. >> >> We are currently reviewing >> Apache Shiro for use with our application that uses GWT. Before Shiro, we >> were >> maintaining a ‘user token key’ on the client side which represented the >> user’s >> logged in session. I believe its usage resembles the Shiro’s session id >> usage. I >> was wanting to just swap out my code in favor of your >> solution. > > Yep, this would be the ideal situation - it should be a 1-to-1 swap. > >> >> I saw a posting of a >> request to make the getSubjectBySessionId method public. Are there plans to >> do this ? > > Nope - but not to worry - there is a more flexible solution in the > works that handles the sessionId case as well as many others. For > example, in your case, you will be able to do this: > > Subject subject = new WebSubjectBuilder(getSecurityManager(), request, > response).setSessionId(sessionId).build(); > > This is *very* new (just added this weekend), but it is much cleaner > than previous mechanisms - it is still in flux and probably won't be > solidified until next week at least. But if you're willing to test it > out, I'm sure we'd appreciate any feedback. > >> I guess another question is >> whether I would even need to manage the session Id in this manner. I guess >> that >> would be more of a question on the GWT side but if you have any input that >> would >> be appreciated. > > As I understand it, GWT does not use cookies for session ids to > eliminate the possibility of cookie-based man-in-the-middle attacks. > As such, there needs to be some other mechanism that sends back the > token (sessionId) with every request. > > I've recently done exactly this for a Flex application, where the flex > app (in some framework code) adds the sessionId to the flex headers, > and then in the server side, the flex headers are inspected for this > session id. > > This is done in a servlet filter that sits in front of the flex > servlet, where the filter acquires the Subject based on this session > id, binds the Subject to the thread (so SecurityUtils.getSubject() may > be used in the application), and then guarantees a cleanup of that > thread in a finally{} block - very similar to how the ShiroFilter > works. > > I'm assuming there is something in GWT that allows you to 'piggyback' > requests/responses in the same way to provide the same functionality, > although I've never set this up for a GWT app myself. Is this easily > accessible in GWT apps? > > - Les > > > > >
