Hi Kalle, Yes, please, open up issues for anything you may see, no matter how small - at least that way it won't be forgotten.
Thanks again for the help - it is much appreciated! - Les On Mon, Aug 31, 2009 at 3:05 PM, Kalle Korhonen<[email protected]> wrote: > Yeap, agree (just wanted to get your opinion without influencing it > too much :) ). I'll open issues as needed and attach patches. Just > FYI, <shiro:guest> tag on on login.jsp isn't being (correctly?) > processed which causes the sample account table not to show up. I > assume I should open issues for any glitch however small they be? > > Kalle > > > > On Mon, Aug 31, 2009 at 8:54 AM, Les Hazlewood<[email protected]> wrote: >> Hi Kalle, >> >> Shouldn't they reside in the web module's test directory? >> >> i.e. src/test/java and src/test/resources >> >> ? >> >> On Mon, Aug 31, 2009 at 12:29 AM, Kalle >> Korhonen<[email protected]> wrote: >>> On Mon, Aug 24, 2009 at 1:10 PM, Les Hazlewood<[email protected]> wrote: >>>> 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 ;) >>> >>> Coming back to this thread (and re-naming subject): if we are to >>> create some web functional tests, where should those tests live? The >>> easiest is as part of one of the sample modules, and it's not bad >>> choice. We could also create a separate module just for the tests, but >>> it may not be as useful - the tests are only useful if you run them >>> all the time and as functional tests, it makes sense they test a >>> "real" application. The way I implemented these for one project is >>> with a few base classes which is nice since they are runnable from >>> your IDE without any changes (as opposed to using Maven integration >>> test phases and/or cargo plugin). Les, others, what do you think? >>> >>> Kalle >>> >>> >>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
