No, I'm not trying to fake it. The original data comes from the user, and
the container puts up the form (login.htm), but I post from there to
login.jsp. What I am trying to do then is force my login servlet to run
immediately after j_security_check.
The user may have attempted access to any of a dozen html or jsp pages and
been trapped by the security system and given the login form. I want him to
fill that in, go through j_security_check then be forced to run my servlet.
Do you know a better way?
It would be perfect if there was a path parameter or "property" to
j_security_check (where_to_go_after_this).
Gerry
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2002 5:40 PM
Subject: Re: Securing access to pages
>
>
> On Fri, 11 Jan 2002, Gerry Duhig wrote:
>
> > Date: Fri, 11 Jan 2002 17:00:30 -0000
> > From: Gerry Duhig <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > Subject: Re: Securing access to pages
> >
> > OK, before I change my whole approach and use a filter or "loggedIn"
flag on
> > al my JSP pages, can someone tell easily why this worked under 3.2 but
> > doesn't under 4.0.1?
> >
>
> Are you trying to "fake" a form based login? That's not going to work at
> all -- the submit to "j_security_check" MUST come from the client, and
> MUST be in response to the container sending the <form-login-page> page.
> The fact that it worked in 3.2 only means you found a pattern that worked
> with that internal implementation of the servlet API, and is guaranteed to
> be non-portable.
>
> There was a thread yesterday (I think) about how to simulate logging in
> without really using container managed security -- by using a Filter that
> created a request wrapper which returned non-null results for
> getRemoteUser, getUserPrincipal, and isUserInRole.
>
> Craig
>
>
> > Login.jsp looks like this:
> > ==================================
> > <%@ page autoFlush="false" %>
> >
> > <%
> > String name = request.getParameter("j_username");
> > String password = request.getParameter("j_password");
> >
> >
> > try
> > {
> > String path="/orders/login";
> > response.setStatus(302,"Found");
> > response.setHeader("Location", path);
> >
> > RequestDispatcher rd = application.getRequestDispatcher(
> > "/j_security_check?j_username="+
> > request.getParameter("j_username")+
> > "&j_password="+request.getParameter("j_password"));
> >
> >
> > rd.include(request,response);
> >
> > if (!response.isCommitted())
> > {
> > response.reset();
> > }
> >
> > }
> > catch (Exception e)
> > {
> > }
> >
> >
> > %>
> > =================================
> > where orders/login is my servlet I want to run after the
j_security_check
> > has been done. It worked before!
> >
> > Gerry
> >
> > ----- Original Message -----
> > From: "Cox, Charlie" <[EMAIL PROTECTED]>
> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
> > Sent: Friday, January 11, 2002 1:59 PM
> > Subject: RE: Securing access to pages
> >
> >
> > > a filter would work great for this. I am doing the exact same
thing(minus
> > > jboss) by using a filter - it can be mapped differently than your
> > > servlets/jsp so it can span as much as it needs to. Just put something
> > into
> > > the session that the filter can check for, and if it is not there, the
> > > filter should redirect(or forward) to the login page.
> > >
> > > Charlie
> > >
> > > > -----Original Message-----
> > > > From: Mike Curwen [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, January 10, 2002 12:27 PM
> > > > To: Tomcat Users List
> > > > Subject: RE: Securing access to pages
> > > >
> > > >
> > > > How about placing a flag in the session, which every JSP (or
> > > > hopefully your
> > > > controller servlet) checks for first.
> > > >
> > > > If it finds the flag (say "loggedIn") then it continues
> > > > processing. If it
> > > > doesn't, it redirects to the login servlet. The login
> > > > servlet would then
> > > > place the "loggedIn" flag into the session, and either send
> > > > them to /index
> > > > or to the page they were trying to access before (which you cleverly
> > > > provided as a parameter when you redirected to the login servlet).
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gerry Duhig [mailto:[EMAIL PROTECTED]]
> > > > Sent: Thursday, January 10, 2002 11:16 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Securing access to pages
> > > >
> > > >
> > > > This is an old question to which I had an answer that worked
> > > > under 3.2.3 but
> > > > now fails under 4.0.1
> > > >
> > > > Using Tomcat embedded in JBoss, I want to secure access to a
> > > > certain set of
> > > > pages and use the JBoss security system to carry out the
> > > > authentication.
> > > >
> > > > Standard stuff. But, as well as going through the JBoss
> > > > security check I
> > > > want to force a user to also go through my own Login servlet.
> > > >
> > > > If users only ever start at /index.htm this is easy, but if
> > > > they remember
> > > > and try to come back in half way down the site, the JBoss
> > > > security works,
> > > > but I need to "insert" a redirect to my login servlet.
> > > >
> > > > Does anyone know how to do this?
> > > >
> > > > Thanks
> > > >
> > > > Gerry
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe:
<mailto:[EMAIL PROTECTED]>
> > > > For additional commands:
<mailto:[EMAIL PROTECTED]>
> > > > Troubles with the list:
<mailto:[EMAIL PROTECTED]>
> > > >
> > >
> > > --
> > > To unsubscribe: <mailto:[EMAIL PROTECTED]>
> > > For additional commands: <mailto:[EMAIL PROTECTED]>
> > > Troubles with the list: <mailto:[EMAIL PROTECTED]>
> > >
> >
> >
> > --
> > To unsubscribe: <mailto:[EMAIL PROTECTED]>
> > For additional commands: <mailto:[EMAIL PROTECTED]>
> > Troubles with the list: <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
