You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2009/08/24 20:48:22 UTC
Re: Shiro - getSubjectBySessionId
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: Shiro - getSubjectBySessionId
Posted by Les Hazlewood <lh...@apache.org>.
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<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: Shiro - getSubjectBySessionId
Posted by Kalle Korhonen <ka...@gmail.com>.
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: Shiro - getSubjectBySessionId
Posted by Les Hazlewood <lh...@apache.org>.
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: Shiro - getSubjectBySessionId
Posted by Kalle Korhonen <ka...@gmail.com>.
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
>>
>>
>>
>>
>>
>