Reading yes, and that work-around need to be in place for anything to work, but it doesn't fix the login issue.
Kalle On Mon, Aug 24, 2009 at 11:48 AM, Les Hazlewood<[email protected]> wrote: > 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 >> >> >> >> >> >
