users@glassfish.java.net

Re: Obtaining LoginException

From: <Jan.Luehe_at_Sun.COM>
Date: Fri, 03 Aug 2007 08:15:58 -0700

Joe,

Shevland, Joe wrote:

>Thanks Jan,
>
>
>
>>If you think about it, this makes sense: While error pages
>>declared via <error-page> receive the request via
>>RequestDispatcher.forward() (meaning any error-related
>>request attributes added to the request prior to the dispatch
>>will be visible to them), the same does not necessarily hold
>>true for error pages declared via <form-error-page>, which
>>should receive the request via an HTTP redirect, meaning any
>>error attributes stored on the request prior to the redirect
>>will be lost.
>>
>>
>
>This makes sense.
>
>
>
>>for why a <form-login-page> resource (and also
>><form-error-page>, since the same resource may be used for
>>both purposes) should receive the request via an HTTP
>>redirect as opposed to a
>>RequestDispatcher.forward() operation. We fixed the above
>>issue only very recently in GlassFish v2 (as of build 57).
>>
>>
>
>(Although here I'm not so sure why using HTTP redirect instead of
>dispatcher.forward(...) fixes the problem, I would've thought the
>opposite way around, but no matter).
>
>

When I said "we fixed the above issue", I was referring to

  https://glassfish.dev.java.net/issues/show_bug.cgi?id=3374
  ("FORM authenticator should issue a redirect (instead of a request
   dispatch "forward") to the login page")

not the NPE. The NPE remains even with the fix for Issue 3374,
since the "javax.servlet.error.status_code" request attribute is not
available to the <form-error-page>, for the reasons explained
above.

With the fix for Issue 3374, we now access the FORM login page
via an HTTP redirect, in order to give the container an opportunity
to intercept the request and enforce any user-data-constraints
(such as a transport-guarantee of CONFIDENTIAL) placed on the
FORM login page. We cannot enforce these requirements during
a RequestDispatch.forward().

So what this means is that if your web.xml protects your resources
with FORM authentication, and places a user-data-constraint
with a transport-guarantee of CONFIDENTIAL onto the FORM
login page only, the container will issue a redirect over https to
the FORM login page, which means the user's FORM login credentials
will be protected via SSL.
Formerly, when the login page was accessed via a
RequestDispatcher.forward(), the credentials used to be transmitted
in the clear for this particular scenario.


Jan


>
>
>>I know this is subtle, but I hope it still makes sense to you.
>>
>>Let me know if you have any questions.
>>
>>
>>Jan
>>
>>
>
>Thanks again, I'll checkout one of the latest builds,
>
>Cheers
>Joe
>
>This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>