tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <bryan_li...@netmeme.org>
Subject Re: JAASRealm/LoginManager questions
Date Thu, 13 Feb 2003 23:41:08 GMT
See below:

On Thu, 2003-02-13 at 16:14, Craig R. McClanahan wrote:


    For Tomcat (at least), such a redirect will not work at all.  The
    magic
    "j_security_check" URL is only enabled when the container did its
    "save
    the original request and display the form login page" trick.  At all
    other
    times, you'll get a 404.
    That assumption does not match what the spec allows.  Even if you
    tried
    this, and even if Tomcat listened to "j_security_check"  at other
    times
    (to make your idea work), there is no way to implement step 7 of the
    required functionality of form based login ("the client is
    redirected to
    the resource using the stored URL path") since there is no such
    thing as a
    stored URL path -- you bypassed Step 1 where the storing took place.


I assume you're talking about Servlet (2.3) spec section SRV12.5.3, Form
Based Authentication.

I'm not proposing to skip step 1.

Instead, I'm proposing that in step 3, instead of presenting a <form>
with action="j_security_check", we give a different action URL, such as
a JSP page or Struts action. (Actually let's just forget the whole
"Filter" angle for the time being).

This JSP page or Struts action takes the request parameters (which will
include things OTHER than j_username and j_password), and will construct
a new request (either as a Servlet forward, or as a browser
POST-by-way-of-Javascript) to "j_security_check", containing the
appropriate parameters.

I hear you saying that this isn't possible, but I'm not seeing anything
in the Servlet spec which says, "The next HTTP request from the client,
after step 1, MUST be the j_security_check POST". Nor does it say, for
example, "if, after step 1, a request comes in for any URI other than
j_security_check, then invalidate the original authentication request
and the
original-requested-URL-wherever-it's-being-kept-for-later-redirecting".

Still no-go? ;)

Bryan


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message