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