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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
