Super - no worries, I knew what I got into by hooking up with trunk snapshots. But don't you like the immediate feedback loop? :) Remember tests - this should have been caught by *some* tests. Been working on web application functional tests using embedded Jetty and htmlunit for a few years - obviously tests for this wouldn't need to so coarse-grained, but the higher level tests do cover a lot of ground. I could contribute some of that work to Shiro if interested.
Kalle On Mon, Aug 24, 2009 at 12:41 PM, Les Hazlewood<[email protected]> wrote: > 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 >>>> >>>> >>>> >>>> >>>> >>> >> >
