How do I support a login form embedded in templates

[Steve B.-4]

I suspect this question has been answered before - unfortunately, I
cannot find the key words to find my answer(s) in archives, etc.

I understand that Tomcat's FORM authorization setup expects me to secure
URL's and then let Tomcat invoke the login form before proceeding to
these URL's when requested.

However, I have a site for which we are creating a new layout which
includes a small login form in the left column. Throughout the site we
use roles defined in the web.xml (checked using isUserInRole() ). I see
many sites use this layout-embedded login form, so I expect there is
some way to set this up in Tomcat. Can someone point me at some info? I
am using Struts in case that matters.

I see many sites use this concept of putting the login form in the
template - does this setup require me to abandon Tomcat's
authentication/authorization mechanisms? My site has many pages and
features which all use the isUserInRole() - I dread having to recode the
whole site just for a simple login form.

TIA for answers or links-to-answers,

Steve B.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve,

On 6/29/2009 1:58 PM, Steve B. wrote:

> I understand that Tomcat's FORM authorization setup expects me to secure
> URL's and then let Tomcat invoke the login form before proceeding to
> these URL's when requested.
>
> However, I have a site for which we are creating a new layout which
> includes a small login form in the left column. Throughout the site we
> use roles defined in the web.xml (checked using isUserInRole() ). I see
> many sites use this layout-embedded login form, so I expect there is
> some way to set this up in Tomcat. Can someone point me at some info? I
> am using Struts in case that matters.

So, you want to be able to invoke j_security_check without first having
requested a protected resource, right? I call this a "drive-by login",
and, unfortunately, Tomcat does not support this directly.

I switched to use securityfilter (http://securityfilter.sourceforge.net)
primarily for this reason. Alternatives include using ACEGI (or "Spring
Security" these days) (I think... Ihaven't used it so I don't know if
drive-by logins are supported) or writing your own authentication and
authorization mechanism. You could even patch Tomcat directly to allow
this kind of login, but you run the risk of tying yourself to a
particular version 9or even patch level) of Tomcat. That's why I
recommend using something like securityfilter.

> I see many sites use this concept of putting the login form in the
> template - does this setup require me to abandon Tomcat's
> authentication/authorization mechanisms? My site has many pages and
> features which all use the isUserInRole() - I dread having to recode the
> whole site just for a simple login form.

FWIW, I find using isUserInRole to be tedious and possibly insecure
(that is, the page developer has to make these kinds of decisions,
instead of an application designer at a higher-level). Do you really
need to have role checking in your JSPs? Typically, by the time the view
is being rendered, permissions are somewhat irrelevant.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpJGpIACgkQ9CaO5/Lv0PCv2QCgsFGy2sc7hIFK3R6dkub2MJIQ
qeAAn1TScfQZGla8LkTGP5lzdqJqdcFM
=GOhP
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Steve B.-4]

Chris,

Thanks, yes, a "drive-by login" is what I am after. I am bummed that
Tomcat does not support this - it seems the common setup on most sites I
visit on the Net. (I suppose it is more accurate to that say I am bummed
that the J2EE standard does not define this behavior as Tomcat is only
implementing those rules.)

I agree with your view of isUserInRole() - but this is a large
application which I am loathe to change everything.

I will check out the packages you mention or role my own security using
a filter or similar.

Thanks again for the response!

Steve B.


Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Steve,
>
> On 6/29/2009 1:58 PM, Steve B. wrote:
>> I understand that Tomcat's FORM authorization setup expects me to secure
>> URL's and then let Tomcat invoke the login form before proceeding to
>> these URL's when requested.
>>
>> However, I have a site for which we are creating a new layout which
>> includes a small login form in the left column. Throughout the site we
>> use roles defined in the web.xml (checked using isUserInRole() ). I see
>> many sites use this layout-embedded login form, so I expect there is
>> some way to set this up in Tomcat. Can someone point me at some info? I
>> am using Struts in case that matters.
>
> So, you want to be able to invoke j_security_check without first having
> requested a protected resource, right? I call this a "drive-by login",
> and, unfortunately, Tomcat does not support this directly.
>
> I switched to use securityfilter (http://securityfilter.sourceforge.net)
> primarily for this reason. Alternatives include using ACEGI (or "Spring
> Security" these days) (I think... Ihaven't used it so I don't know if
> drive-by logins are supported) or writing your own authentication and
> authorization mechanism. You could even patch Tomcat directly to allow
> this kind of login, but you run the risk of tying yourself to a
> particular version 9or even patch level) of Tomcat. That's why I
> recommend using something like securityfilter.
>
>> I see many sites use this concept of putting the login form in the
>> template - does this setup require me to abandon Tomcat's
>> authentication/authorization mechanisms? My site has many pages and
>> features which all use the isUserInRole() - I dread having to recode the
>> whole site just for a simple login form.
>
> FWIW, I find using isUserInRole to be tedious and possibly insecure
> (that is, the page developer has to make these kinds of decisions,
> instead of an application designer at a higher-level). Do you really
> need to have role checking in your JSPs? Typically, by the time the view
> is being rendered, permissions are somewhat irrelevant.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkpJGpIACgkQ9CaO5/Lv0PCv2QCgsFGy2sc7hIFK3R6dkub2MJIQ
> qeAAn1TScfQZGla8LkTGP5lzdqJqdcFM
> =GOhP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daniel Henrique Alves Lima]

        Hi, Steve and Chris.

        Steve, can you use AJAX to request a protected resource and to provide
username/password to your real login page (configured at web.xml) or
directly to j_security_check ?
        I don't know if this will work (and if this is what you have in mind),
but:

        1. Design your "unprotected" pages at your will (including a small
login box);
        2. When user fills the form in your small login box,
                - Send a JS XmlHttpRequest (AJAX) to a protected resource (for
instance protected_resource.jsp);
                - Send a JS XmlHttoRequest to your real login page (login.jsp) or to
j_security_check passing j_username and j_password extracted from your
small login page (you can detect if login has failed or not using the
response of XmlHttpRequest) ;
                - If is all right, reload the page or load any other resource that you
want.


        Will it work ?


On Tue, 2009-06-30 at 08:41 -0400, Steve B. wrote:

> Chris,
>
> Thanks, yes, a "drive-by login" is what I am after. I am bummed that
> Tomcat does not support this - it seems the common setup on most sites I
> visit on the Net. (I suppose it is more accurate to that say I am bummed
> that the J2EE standard does not define this behavior as Tomcat is only
> implementing those rules.)
>
> I agree with your view of isUserInRole() - but this is a large
> application which I am loathe to change everything.
>
> I will check out the packages you mention or role my own security using
> a filter or similar.
>
> Thanks again for the response!
>
> Steve B.
>
>
> Christopher Schultz wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Steve,
> >
> > On 6/29/2009 1:58 PM, Steve B. wrote:
> >> I understand that Tomcat's FORM authorization setup expects me to secure
> >> URL's and then let Tomcat invoke the login form before proceeding to
> >> these URL's when requested.
> >>
> >> However, I have a site for which we are creating a new layout which
> >> includes a small login form in the left column. Throughout the site we
> >> use roles defined in the web.xml (checked using isUserInRole() ). I see
> >> many sites use this layout-embedded login form, so I expect there is
> >> some way to set this up in Tomcat. Can someone point me at some info? I
> >> am using Struts in case that matters.
> >
> > So, you want to be able to invoke j_security_check without first having
> > requested a protected resource, right? I call this a "drive-by login",
> > and, unfortunately, Tomcat does not support this directly.
> >
> > I switched to use securityfilter (http://securityfilter.sourceforge.net)
> > primarily for this reason. Alternatives include using ACEGI (or "Spring
> > Security" these days) (I think... Ihaven't used it so I don't know if
> > drive-by logins are supported) or writing your own authentication and
> > authorization mechanism. You could even patch Tomcat directly to allow
> > this kind of login, but you run the risk of tying yourself to a
> > particular version 9or even patch level) of Tomcat. That's why I
> > recommend using something like securityfilter.
> >
> >> I see many sites use this concept of putting the login form in the
> >> template - does this setup require me to abandon Tomcat's
> >> authentication/authorization mechanisms? My site has many pages and
> >> features which all use the isUserInRole() - I dread having to recode the
> >> whole site just for a simple login form.
> >
> > FWIW, I find using isUserInRole to be tedious and possibly insecure
> > (that is, the page developer has to make these kinds of decisions,
> > instead of an application designer at a higher-level). Do you really
> > need to have role checking in your JSPs? Typically, by the time the view
> > is being rendered, permissions are somewhat irrelevant.
> >
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAkpJGpIACgkQ9CaO5/Lv0PCv2QCgsFGy2sc7hIFK3R6dkub2MJIQ
> > qeAAn1TScfQZGla8LkTGP5lzdqJqdcFM
> > =GOhP
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

--
"If there must be trouble, let it be in my day,
 that my child may have peace."

Thomas Paine


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[awarnier]

Daniel Henrique Alves Lima wrote:

> Hi, Steve and Chris.
>
> Steve, can you use AJAX to request a protected resource and to provide
> username/password to your real login page (configured at web.xml) or
> directly to j_security_check ?
> I don't know if this will work (and if this is what you have in mind),
> but:
>
> 1. Design your "unprotected" pages at your will (including a small
> login box);
> 2. When user fills the form in your small login box,
> - Send a JS XmlHttpRequest (AJAX) to a protected resource (for
> instance protected_resource.jsp);

It seems to me that you can skip the above step, no ?
And do the following one immediately.

> - Send a JS XmlHttoRequest to your real login page (login.jsp) or to
> j_security_check passing j_username and j_password
as parameters.

extracted from your
> small login page (you can detect if login has failed or not using the
> response of XmlHttpRequest) ;
> - If is all right, reload the page or load any other resource that you
> want.
>

I think the problem is here (but probably solvable) :
In return to a successful login by the XmlHttpRequest, the server sends
back a page, along with a "set-cookie" header, or with embedded
";jsessionid=.." parameters.  This response page is received by the
XmlHttpRequest handler.  This does not automatically (I think) mean that
the browser (as a whole) knows about it, nor that any next outgoing
request is going to magically include the jsessionid.
I believe there is more work to do here..
;-)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daniel Henrique Alves Lima]

On Tue, 2009-06-30 at 16:32 +0200, André Warnier wrote:
> Daniel Henrique Alves Lima wrote:

> > 2. When user fills the form in your small login box,
> > - Send a JS XmlHttpRequest (AJAX) to a protected resource (for
> > instance protected_resource.jsp);
>
> It seems to me that you can skip the above step, no ?
> And do the following one immediately.

        I don't know if Tomcat likes a directly call to login
page/j_security_check (i think i've just had troubles using this
approach).
        I've did a similar thing to force an applet to authenticate the user
using Tomcat's declarative security in my webapp a long time ago.


>
> I think the problem is here (but probably solvable) :
> In return to a successful login by the XmlHttpRequest, the server sends
> back a page, along with a "set-cookie" header, or with embedded
> ";jsessionid=.." parameters.  

        I really don't know what is the exact moment when jsessionid is
created. I think that "set-cookie" will be handled by the browser as a
whole (just testing to be sure), but ';jsessionid=' could be a problem.
        In previous applet example, i've used javascript (called from the
applet) to ask the value of JSESSIONID cookie, after a successfully
authentication.


> This response page is received by the
> XmlHttpRequest handler.  This does not automatically (I think) mean that
> the browser (as a whole) knows about it, nor that any next outgoing
> request is going to magically include the jsessionid.

        If you create an unauthenticated session before, will Tomcat "reuse"
sessionid after authentication ? If it does, you just need to do a
request.getSession(true) in the first (unprotected) resource of your
webapp.


--
"If there must be trouble, let it be in my day,
 that my child may have peace."

Thomas Paine


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...