You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Kalle Korhonen <ka...@gmail.com> on 2009/08/31 06:29:56 UTC
Web functional testing (was Re: Shiro - getSubjectBySessionId)
On Mon, Aug 24, 2009 at 1:10 PM, Les Hazlewood<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ya...@yahoo.com> 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 <lh...@apache.org>
>>>>>> To: David Higginbotham <ya...@yahoo.com>
>>>>>> 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<ya...@yahoo.com> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Web functional testing (was Re: Shiro - getSubjectBySessionId)
Posted by Les Hazlewood <lh...@apache.org>.
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<ka...@gmail.com> 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<lh...@apache.org> 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<ka...@gmail.com> wrote:
>>> On Mon, Aug 24, 2009 at 1:10 PM, Les Hazlewood<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ya...@yahoo.com> 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 <lh...@apache.org>
>>>>>>>>> To: David Higginbotham <ya...@yahoo.com>
>>>>>>>>> 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<ya...@yahoo.com> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Web functional testing (was Re: Shiro - getSubjectBySessionId)
Posted by Kalle Korhonen <ka...@gmail.com>.
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<lh...@apache.org> 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<ka...@gmail.com> wrote:
>> On Mon, Aug 24, 2009 at 1:10 PM, Les Hazlewood<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ya...@yahoo.com> 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 <lh...@apache.org>
>>>>>>>> To: David Higginbotham <ya...@yahoo.com>
>>>>>>>> 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<ya...@yahoo.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Web functional testing (was Re: Shiro - getSubjectBySessionId)
Posted by Les Hazlewood <lh...@apache.org>.
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<ka...@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 1:10 PM, Les Hazlewood<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ka...@gmail.com> 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<lh...@apache.org> 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<ya...@yahoo.com> 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 <lh...@apache.org>
>>>>>>> To: David Higginbotham <ya...@yahoo.com>
>>>>>>> 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<ya...@yahoo.com> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>