Correct - now that I'm in the code, I noticed that I did make changes on Saturday that would have prevented this from happening, but I forgot to check them in :)
I'll be committing those changes soon. On Mon, Aug 24, 2009 at 3:09 PM, Kalle Korhonen<[email protected]> wrote: > 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 >>> >>> >>> >>> >>> >> >
