I for one am absolutely interested! Please feel free to send whatever you may find useful. A patch would be easiest - and yes, I'll happily use Tortoise if it's not compliant w/ IntelliJ ;)
Much obliged, Les On Mon, Aug 24, 2009 at 3:58 PM, Kalle Korhonen<[email protected]> wrote: > 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
