You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sid Sidney <pv...@yahoo.com> on 2009/05/04 15:26:47 UTC
How to make request parameters available to a login.jsp?
Hi, I have posted this question in many different forum, but I still have not found an answer. Perhaps, I will in this list.
I have a secured resource in Tomcat.
My resources are secured via FORM authentication (j_security_check).
The secured resources are requested from an external page like this:
<form method="post" action="http://localhost:8080/testApp/secured/userHome.do" name="userHomeForm">
<input type="hidden" name="mydata" value="MYDATA"/>
<input type="submit" value="Enter Here"/>
</form>
This my login.jsp. I have a business requirement that needs to access the "mydata" request parameter from this page.
The values are always null when the requests are made
via a "post". However, this works when the request is made via a "get" I
cannot change my forms to "get" method that is just not possible. If anyone has any
idea what we need to do, please please help us out. Thanks in advance! This works in Tomcat 5.0. But not in the newer releases. And we need to move to a newer release.
(I did not paste my entire login.jsp. But I can added if requested) Thanks in advance.
<%
request.setCharacterEncoding("UTF-
java.util.Enumeration paramNames = request.getParameterNames();
out.println("<p>My Param Names Enum:</p>");
while(paramNames.hasMoreElements()) {
out.println("<p>Param Name: " + paramNames.nextElement() + "</p>");
}
String consignmentId = request.getParameter( "mydata" );
out.println("<p>My Data: " + consignmentId + "</p>");
%>
<form method="post" action='<%= response.encodeURL("j_security_check") %>' >
<table border="0" >
<tr>
<th >Username:</th>
<td ><input type="text" name="j_username"></td>
</tr>
Re: How to make request parameters available to a login.jsp?
Posted by André Warnier <aw...@ice-sa.com>.
Sid Sidney wrote:
> One thing I've just found out is that if I enable the <valve> RequestDumperValue</valve>
> The post data becomes available to the login.jsp.
>
> <Valve className="org.apache.catalina.valves.RequestDumperValve"/>
>
> I'm going to have to look more at this.
But that one's kind of "expensive".
>
Again I'm not the Tomcat expert here.
But it seems to me that if you are going to go that path, and use
something that is not "officially" in either Tomcat or in the Servlet
Spec, you run the risk of it stopping from working at some undeterminate
moment/version in the future.
Maybe you would do better rethinking your logic a bit, and see if there
is not an easier way to determine who the client is, rather than by
digging out the previous request data (of which there might not be any).
You could for example pick up the IP of the customer and determine that
way who he is, before even sending the login page. That could probably
be done with a servlet filter.
How many different "customers" are we talking about ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sid,
On 5/4/2009 10:20 PM, Sid Sidney wrote:
> One thing I've just found out is that if I enable the <valve> RequestDumperValue</valve>
> The post data becomes available to the login.jsp.
>
> <Valve className="org.apache.catalina.valves.RequestDumperValve"/>
That's an interesting hack: the RequestDumperValve works by
siphoning-off the POST data and /also/ storing those parameters into the
request such that request.getParameter() and friends all work properly.
Since the valve operates /before/ the security valve, you get the added
benefit of your parameters working in the login page.
> I'm going to have to look more at this.
Check to see how the RequestDumperValve populated the request's
parameter map. Maybe that would help you (or a TC dev) create a patch
for this issue.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoAO40ACgkQ9CaO5/Lv0PBswwCfcW8aZsXlesvDWvNtuamEfzBZ
hDQAoLW2+X7bFDi3ETIW/dPnQWso/EdG
=JQIR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Sid Sidney <pv...@yahoo.com>.
One thing I've just found out is that if I enable the <valve> RequestDumperValue</valve>
The post data becomes available to the login.jsp.
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
I'm going to have to look more at this.
--- On Mon, 5/4/09, Sid Sidney <pv...@yahoo.com> wrote:
From: Sid Sidney <pv...@yahoo.com>
Subject: Re: How to make request parameters available to a login.jsp?
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Monday, May 4, 2009, 9:14 PM
Hi Andre,
I agree it sounds strange, but there is a legitimate business requirement for
this data to be available in the login page. As I stated in an earlier reply, We
use this data to personalize the look and feel of our application based on this
data. This used to work in earlier versions of Tomcat. I'm affraid that
you are right, and I am going to have to dig into the tomcat code. But I was
hoping I won't have to do that.
--- On Mon, 5/4/09, André Warnier <aw...@ice-sa.com> wrote:
From: André Warnier <aw...@ice-sa.com>
Subject: Re: How to make request parameters available to a login.jsp?
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Monday, May 4, 2009, 2:45 PM
Sid Sidney wrote:
> Tomcat does remembers the original "POST data". I know because
once a user successfuly sings in, the original "POST data" is
available either from a jsp or servlet. The problem is that it is not
available
within the login.jsp page.
Why would you need that strange thing ? ;-)
Anyway, putting together Chuck's response and mine and yours, it appears
that this POST data is thus stuffed away somewhere by Tomcat.
You might be able to do some detective work, find out where, and go get it.
It still sounds strange (to me) that you would need this at the moment of
running your login.jsp though..
> --- On Mon, 5/4/09, Caldarale, Charles R
<Ch...@unisys.com> wrote:
> From: Caldarale, Charles R <Ch...@unisys.com>
> Subject: RE: How to make request parameters available to a login.jsp?
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Monday, May 4, 2009, 2:02 PM
>
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Subject: Re: How to make request parameters available to a login.jsp?
>>
>> Except that it (usually) breaks down if the original request was a
POST. Because then, the server would have needed to remember, not only the URI
of the original request, but also
>> the content (body) of it, since it was made via a POST.
>>
>> I am willing to be impressed, but I don't think that Tomcat's
form-based authentication mechanism would be able to read the
>> original POST data, memorise it somewhere, and then "replay
it"
>> when it gets the login form duly completed.
>
> You need to be impressed: Tomcat does exactly what you don't think
it's
> able to. Read the servlet spec, and the doc for the maxSavePostSize
attribute
> of the <Connector> element.
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Attributes
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Sid Sidney <pv...@yahoo.com>.
Hi Andre,
I agree it sounds strange, but there is a legitimate business requirement for this data to be available in the login page. As I stated in an earlier reply, We use this data to personalize the look and feel of our application based on this data. This used to work in earlier versions of Tomcat. I'm affraid that you are right, and I am going to have to dig into the tomcat code. But I was hoping I won't have to do that.
--- On Mon, 5/4/09, André Warnier <aw...@ice-sa.com> wrote:
From: André Warnier <aw...@ice-sa.com>
Subject: Re: How to make request parameters available to a login.jsp?
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Monday, May 4, 2009, 2:45 PM
Sid Sidney wrote:
> Tomcat does remembers the original "POST data". I know because
once a user successfuly sings in, the original "POST data" is
available either from a jsp or servlet. The problem is that it is not available
within the login.jsp page.
Why would you need that strange thing ? ;-)
Anyway, putting together Chuck's response and mine and yours, it appears
that this POST data is thus stuffed away somewhere by Tomcat.
You might be able to do some detective work, find out where, and go get it.
It still sounds strange (to me) that you would need this at the moment of
running your login.jsp though..
> --- On Mon, 5/4/09, Caldarale, Charles R
<Ch...@unisys.com> wrote:
> From: Caldarale, Charles R <Ch...@unisys.com>
> Subject: RE: How to make request parameters available to a login.jsp?
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Monday, May 4, 2009, 2:02 PM
>
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Subject: Re: How to make request parameters available to a login.jsp?
>>
>> Except that it (usually) breaks down if the original request was a
POST. Because then, the server would have needed to remember, not only the URI
of the original request, but also
>> the content (body) of it, since it was made via a POST.
>>
>> I am willing to be impressed, but I don't think that Tomcat's
form-based authentication mechanism would be able to read the
>> original POST data, memorise it somewhere, and then "replay
it"
>> when it gets the login form duly completed.
>
> You need to be impressed: Tomcat does exactly what you don't think
it's
> able to. Read the servlet spec, and the doc for the maxSavePostSize
attribute
> of the <Connector> element.
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Attributes
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by André Warnier <aw...@ice-sa.com>.
Sid Sidney wrote:
> Tomcat does remembers the original "POST data". I know because once a user successfuly sings in, the original "POST data" is available either from a jsp or servlet. The problem is that it is not available within the login.jsp page.
>
Why would you need that strange thing ? ;-)
Anyway, putting together Chuck's response and mine and yours, it appears
that this POST data is thus stuffed away somewhere by Tomcat.
You might be able to do some detective work, find out where, and go get it.
It still sounds strange (to me) that you would need this at the moment
of running your login.jsp though..
> --- On Mon, 5/4/09, Caldarale, Charles R <Ch...@unisys.com> wrote:
> From: Caldarale, Charles R <Ch...@unisys.com>
> Subject: RE: How to make request parameters available to a login.jsp?
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Monday, May 4, 2009, 2:02 PM
>
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Subject: Re: How to make request parameters available to a login.jsp?
>>
>> Except that it (usually) breaks down if the original request
>> was a POST. Because then, the server would have needed to
>> remember, not only the URI of the original request, but also
>> the content (body) of it, since it was made via a POST.
>>
>> I am willing to be impressed, but I don't think that Tomcat's
>> form-based authentication mechanism would be able to read the
>> original POST data, memorise it somewhere, and then "replay it"
>> when it gets the login form duly completed.
>
> You need to be impressed: Tomcat does exactly what you don't think it's
> able to. Read the servlet spec, and the doc for the maxSavePostSize attribute
> of the <Connector> element.
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Attributes
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to make request parameters available to a login.jsp?
Posted by Sid Sidney <pv...@yahoo.com>.
Tomcat does remembers the original "POST data". I know because once a user successfuly sings in, the original "POST data" is available either from a jsp or servlet. The problem is that it is not available within the login.jsp page.
--- On Mon, 5/4/09, Caldarale, Charles R <Ch...@unisys.com> wrote:
From: Caldarale, Charles R <Ch...@unisys.com>
Subject: RE: How to make request parameters available to a login.jsp?
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Monday, May 4, 2009, 2:02 PM
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: How to make request parameters available to a login.jsp?
>
> Except that it (usually) breaks down if the original request
> was a POST. Because then, the server would have needed to
> remember, not only the URI of the original request, but also
> the content (body) of it, since it was made via a POST.
>
> I am willing to be impressed, but I don't think that Tomcat's
> form-based authentication mechanism would be able to read the
> original POST data, memorise it somewhere, and then "replay it"
> when it gets the login form duly completed.
You need to be impressed: Tomcat does exactly what you don't think it's
able to. Read the servlet spec, and the doc for the maxSavePostSize attribute
of the <Connector> element.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Attributes
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to make request parameters available to a login.jsp?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: How to make request parameters available to a login.jsp?
>
> Except that it (usually) breaks down if the original request
> was a POST. Because then, the server would have needed to
> remember, not only the URI of the original request, but also
> the content (body) of it, since it was made via a POST.
>
> I am willing to be impressed, but I don't think that Tomcat's
> form-based authentication mechanism would be able to read the
> original POST data, memorise it somewhere, and then "replay it"
> when it gets the login form duly completed.
You need to be impressed: Tomcat does exactly what you don't think it's able to. Read the servlet spec, and the doc for the maxSavePostSize attribute of the <Connector> element.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Attributes
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by André Warnier <aw...@ice-sa.com>.
Sid Sidney wrote:
> Hi, I have posted this question in many different forum, but I still have not found an answer. Perhaps, I will in this list.
>
Not being the Tomcat expert, I don't know how Tomcat (in its different
versions) handles this, but you may be encountering the following issue :
A HTTP request made as a GET, sends all the data in the request URL (as
query-string).
A HTTP request made as a POST on the the other hand sends the data in
the body of the request.
Now the server receives the request, and determines that this URI needs
authentication, and that the authentication in question is a
"form-based" authentication. So it sends back, not the content that the
client expected, but instead, it sends a login form.
(The browser however does not know that substitution, it thinks that
this is the real response.)
The user fills in the login form, and submits it to the server.
The server receives the login form request (whatever it is), processes
it, and determines that the login is correct.
Then (clever he), he has noted somewhere what the original request URI
was for this same browser (when it originally requested the protected
content), and it re-directs the request to that original URI.
So now the browser (or client) receives the content for the original URI
that it requested.
Quite good, he ?
Except that it (usually) breaks down if the original request was a POST.
Because then, the server would have needed to remember, not only the URI
of the original request, but also the content (body) of it, since it was
made via a POST.
I am willing to be impressed, but I don't think that Tomcat's form-based
authentication mechanism would be able to read the original POST data,
memorise it somewhere, and then "replay it" when it gets the login form
duly completed.
You would not have the same issue if the required authentication was a
"Basic" authentication, because then the browser would know that it
needs to re-submit the original request, complete with body and with an
authentication header.
But in this case, the browser just does not know that, because it has
received a perfectly OK 200 response when it tried to access the
resource the first time. It is fooled..
So now let's hear what the gurus have to say..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 5/7/2009 7:12 AM, Gregor Schneider wrote:
> Chris, maybe you'll get the hang of this Valve if I explain the
> business-requirement I had:
I think I understand your business requirement. It's your code I don't
understand.
> Now let's assume, session is timing out, and after that timeout the
> user selects one of the menue-entries on the left side.
> What's happening?
>
> The url requested will look like "http://mysite/protected/some_stuff"
It will look like http://mysite/protected/some_stuff.html
> The HTML in that case looks like
>
> <a href="http://mysite/protected/some_stuff.html"
> target="some_content">menue4</a>
>
> No this triggers j_security_check, but unfortunately j_security_check
> just stores the last request, and after passing the credentials,
> you'll won't see your "index.html" but "/protected/some_stuff.html" -
> without the iframe and aboviously without the menue.
Where did index.html come from? Your link should open in the
"some_content" window. So, you'll get the login page shown in your
iframe, then you login, and then /protected/some_stuff.html is shown in
the iframe. Is that not what you want?
> So the purpose of this Valve is to provide a mechanism which makes
> sure, that if a non-authorized request comes in requesting anything
> else but your "/protected/index.html", that the original request (i.e.
> "/protected/some_stuff") is replaced by
> "/protected/index.html" (or any other url being specified in the
> Valve-descriptor).
Wow. You're right: I didn't understand your business requirement. I
think this use case is ... minimally represented among web sites.
> This basically says, that all /non-authorized/ requests to the
> protected content will be re-routed to "/protected/index.html"
> (redirectAfterAuth).
Note that this violates the servlet spec, which you are certainly free
to do.
>> 1. Why can't the "redirectAfterAuth" path be within the protected space?
>
> Actually I do not see why this shouldn't be possible:
Sorry, looking back, I'm not sure why I made that statement.
> If you take a look at the first condition:
>
> + if (aRequest.getRequestURI().startsWith(protectedPath)
> + && !aRequest.getRequestURI().startsWith(redirectAfterAuth)
> + && !aRequest.getRequestURI().startsWith(
> + "/j_security_check", 10)) {
>
> Basically it says:
>
> - Only URLs are handled being in my protected area
> - the URL must /not/ be equal my default protected starting-URL
No, it says that it can't start with your redirectAfterAuth URL.
> - the URL requested must /not/ be j_security_check
No, this checks characters 10-16 of your URL.
> The two latter conditions are necessary to avoid an infinite loop when
> accessing protected content
Why? If the user is not authenticated, they get redirected. If the user
is authenticated, nothing happens. The loop only occurs when the
redirectAfterAuth URL lives within the protected space, which is what
you said you wanted. Presumably, the container intervenes and serves the
login page before the loop is allowed to occur.
Note that you have an extraneous level of if/then... the authType check
could just as easily be a part of the 3-part predicate just discussed.
>> 2. Why do you check to see if the request URI /startsWith/ the
>> redirectAfterAuth instead of being equal to it?
>
> Because there might be some parameters after the adress in the URL -
> i.e., if Cookies are not possible so that the session-information is
> stored within the URL
Check the spec: the ';jsessionid' will not be included in
request.getRequestURI.
> When "j_security_check" is triggered, the URL will look like
>
> /protected/j_security_check
I'm not sure that's guaranteed. Your app may work this way, but someone
else's app might use /j_security_check no matter what (i.e. the
"protected" prefix does not have to be in front of j_security_check in
order for logins to work).
> Why do I not ask for the String ending with "j_security_check"?
> I was not sure how that URL looks like if session-info is encoded
> within the URL - therefore I'm using startsWith()
See above. It's easy to test this, btw.
>> 4. Why are killing the session if the authtype is null?
>
> Because we experienced with some users, esp. behind company-proxies,
> that situations may occur where a session still exists, but the
> Principal was null.
> Therefore, if Principal is null, better be safe than sorry and make
> sure you definitely have a new session.
You already have a session... why not simply allow it to live? Having a
session and being authenticated are not the same (though the inverse
/is/ true for FORM authentication).
>> 5. Why does your valve pass-through any requests before the component
>> has "started"? Is there a valid use case where NOT performing these
>> checks and redirects is appropriate?
>
> Nope. I took this code from AccessLogValve (I believe it was that
> one), and my assumption was those checks don't make sense /before/ the
> Valve is completely set (started).
> If you feel that a different approach does make more sense here, I'm
> happy for your suggestions
I'd be surprised if requests were accepted before all Valves were
brought into service. But, I've been surprised by Tomcat's /filter/
behavior before (i.e. filters who throw exceptions during init() are
happily put into service and can fail all they want!).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoDWTwACgkQ9CaO5/Lv0PCSMwCdHk+NMxyXW7EHxI1nXmjJeRbp
0KwAniyQPk0lAHV+DSHYVHThxfTvPEl7
=BJ4Z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Pid <p...@pidster.com>.
Gregor Schneider wrote:
> Pid,
>
> On Thu, May 7, 2009 at 2:01 PM, Pid <p...@pidster.com> wrote:
>> Alternative:
>>
>> I don't have this to hand anymore since the original site was changed
>> and I'm not the dev for it anymore, but we put a frame-busting
>> javascript on the login page instead, it loaded our preferred start URL
>> instead of just busting the frame.
>>
>> Not ideal if you want to do it all server-side, but it worked for us.
>>
>
> doesn't work for us for several reasons:
>
> - few thoused html-pages, meaning you'll have to put the
> frame-breakout into /every/ page
We only put it into the login page, but maybe I'm misunderstanding your
setup. Not to worry.
> - although most pages are generated by a "tool" *sic*, the
> <head>-sections are mostly different to each other so that we also
> can't generate such a frame-breakout for every page.
> Doing so by hand is way too much effort
>
> Other than that, your solution is fine, however, due to the above that
> doesn't work for us.
Fair enough.
p
> Cheers
>
> Gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Gregor Schneider <rc...@googlemail.com>.
Pid,
On Thu, May 7, 2009 at 2:01 PM, Pid <p...@pidster.com> wrote:
> Alternative:
>
> I don't have this to hand anymore since the original site was changed
> and I'm not the dev for it anymore, but we put a frame-busting
> javascript on the login page instead, it loaded our preferred start URL
> instead of just busting the frame.
>
> Not ideal if you want to do it all server-side, but it worked for us.
>
doesn't work for us for several reasons:
- few thoused html-pages, meaning you'll have to put the
frame-breakout into /every/ page
- although most pages are generated by a "tool" *sic*, the
<head>-sections are mostly different to each other so that we also
can't generate such a frame-breakout for every page.
Doing so by hand is way too much effort
Other than that, your solution is fine, however, due to the above that
doesn't work for us.
Cheers
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available
@ http://pgpkeys.pca.dfn.de:11371
@ http://pgp.mit.edu:11371/
skype:rc46fi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Pid <p...@pidster.com>.
Gregor Schneider wrote:
> Chris,
>
> On Thu, May 7, 2009 at 4:07 AM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> A few questions:
>>
> Chris, maybe you'll get the hang of this Valve if I explain the
> business-requirement I had:
>
> My primary target was to cirumvent the problem having a framed
> web-app, where some content is requested after the session has timed
> out.
>
> let's say we have the following website-structure:
>
> +----------------------------------------+
> | menue1| |
> | menue2| some_content |
> | menue3| |
> | menue4| |
> | menue5| |
> +-----------------------------------------+
>
> (hope the formatting is ok )
>
> "some_content" is an iframe, and the content of this iframe is changed
> by selecting one of the left menue-items.
> The iframe is specified in "index.html such as:
>
> <html>
> <body>
> <iframe name="some_content" src="/protected/somepage.html">
> Some iframe-error-message
> </iframe>
> </body>
> </html>
>
> Now let's assume, session is timing out, and after that timeout the
> user selects one of the menue-entries on the left side.
> What's happening?
>
> The url requested will look like "http://mysite/protected/some_stuff"
>
> The HTML in that case looks like
>
> <a href="http://mysite/protected/some_stuff.html"
> target="some_content">menue4</a>
>
> No this triggers j_security_check, but unfortunately j_security_check
> just stores the last request, and after passing the credentials,
> you'll won't see your "index.html" but "/protected/some_stuff.html" -
> without the iframe and aboviously without the menue.
Alternative:
I don't have this to hand anymore since the original site was changed
and I'm not the dev for it anymore, but we put a frame-busting
javascript on the login page instead, it loaded our preferred start URL
instead of just busting the frame.
Not ideal if you want to do it all server-side, but it worked for us.
p
> So the purpose of this Valve is to provide a mechanism which makes
> sure, that if a non-authorized request comes in requesting anything
> else but your "/protected/index.html", that the original request (i.e.
> "/protected/some_stuff") is replaced by
> "/protected/index.html" (or any other url being specified in the
> Valve-descriptor).
>
> Now take a look at some example-Valve-descriptor:
>
> <Context>
> <Valve className="org.apache.catalina.valves.LoginValve"
> protectedPath="/protected"
> redirectAfterAuth="/protected/index.html"/>
> </Context>
>
> This basically says, that all /non-authorized/ requests to the
> protected content will be re-routed to "/protected/index.html"
> (redirectAfterAuth).
>
>> 1. Why can't the "redirectAfterAuth" path be within the protected space?
>>
>
> Actually I do not see why this shouldn't be possible: Actually the
> idea is, that redirectAfterAuth /must/ be in the protected area
>
> If you take a look at the first condition:
>
> + if (aRequest.getRequestURI().startsWith(protectedPath)
> + && !aRequest.getRequestURI().startsWith(redirectAfterAuth)
> + && !aRequest.getRequestURI().startsWith(
> + "/j_security_check", 10)) {
>
> Basically it says:
>
> - Only URLs are handled being in my protected area
> - the URL must /not/ be equal my default protected starting-URL
> - the URL requested must /not/ be j_security_check
>
> The two latter conditions are necessary to avoid an infinite loop when
> accessing protected content
>
>> 2. Why do you check to see if the request URI /startsWith/ the
>> redirectAfterAuth instead of being equal to it?
>
> Because there might be some parameters after the adress in the URL -
> i.e., if Cookies are not possible so that the session-information is
> stored within the URL
>
>> 3. Why are you checking to see if characters 10 - 16 of the request URI
>> are "y_check". Why not check for the whole "j_security_check" string?
>> Why not check the /end/ of the request URI for j_security_check,
>> since the URI for j_security_check is not required to be
>> /j_security_check but pretty much */j_security_check?
>
> You are right with this:
>
> Actually I made a mistake here:
>
> When "j_security_check" is triggered, the URL will look like
>
> /protected/j_security_check
>
> As you can see, in this example it works since "/protected" is exactly
> 10 characters long.
>
> Therefore, the correct code would be
>
> + && !aRequest.getRequestURI().startsWith(
> + "/j_security_check", protectedPath.length())) {
>
> I'll correct that with a new patch during the weekend.
>
> Why do I not ask for the String ending with "j_security_check"?
> I was not sure how that URL looks like if session-info is encoded
> within the URL - therefore I'm using startsWith()
>
>> 4. Why are killing the session if the authtype is null?
>
> Because we experienced with some users, esp. behind company-proxies,
> that situations may occur where a session still exists, but the
> Principal was null.
> Therefore, if Principal is null, better be safe than sorry and make
> sure you definately have a new session
>
>> 5. Why does your valve pass-through any requests before the component
>> has "started"? Is there a valid use case where NOT performing these
>> checks and redirects is appropriate?
>
> Nope. I took this code from AccessLogValve (I believe it was that
> one), and my assumption was those checks don't make sense /before/ the
> Valve is completely set (started).
> If you feel that a different approach does make more sense here, I'm
> happy for your suggestions
>
>> It appears that your valve does nothing but murder the session and
>> redirect the user if authtype=null and you are requesting a resource
>> from a particular URI space. This does not seem particularly useful.
>>
>> Maybe I'm missing something subtle.
>>
>
> Seems to be - see my explanations on top.
>
> Cheers
>
> Gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Gregor Schneider <rc...@googlemail.com>.
Chris,
On Thu, May 7, 2009 at 4:07 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> A few questions:
>
Chris, maybe you'll get the hang of this Valve if I explain the
business-requirement I had:
My primary target was to cirumvent the problem having a framed
web-app, where some content is requested after the session has timed
out.
let's say we have the following website-structure:
+----------------------------------------+
| menue1| |
| menue2| some_content |
| menue3| |
| menue4| |
| menue5| |
+-----------------------------------------+
(hope the formatting is ok )
"some_content" is an iframe, and the content of this iframe is changed
by selecting one of the left menue-items.
The iframe is specified in "index.html such as:
<html>
<body>
<iframe name="some_content" src="/protected/somepage.html">
Some iframe-error-message
</iframe>
</body>
</html>
Now let's assume, session is timing out, and after that timeout the
user selects one of the menue-entries on the left side.
What's happening?
The url requested will look like "http://mysite/protected/some_stuff"
The HTML in that case looks like
<a href="http://mysite/protected/some_stuff.html"
target="some_content">menue4</a>
No this triggers j_security_check, but unfortunately j_security_check
just stores the last request, and after passing the credentials,
you'll won't see your "index.html" but "/protected/some_stuff.html" -
without the iframe and aboviously without the menue.
So the purpose of this Valve is to provide a mechanism which makes
sure, that if a non-authorized request comes in requesting anything
else but your "/protected/index.html", that the original request (i.e.
"/protected/some_stuff") is replaced by
"/protected/index.html" (or any other url being specified in the
Valve-descriptor).
Now take a look at some example-Valve-descriptor:
<Context>
<Valve className="org.apache.catalina.valves.LoginValve"
protectedPath="/protected"
redirectAfterAuth="/protected/index.html"/>
</Context>
This basically says, that all /non-authorized/ requests to the
protected content will be re-routed to "/protected/index.html"
(redirectAfterAuth).
> 1. Why can't the "redirectAfterAuth" path be within the protected space?
>
Actually I do not see why this shouldn't be possible: Actually the
idea is, that redirectAfterAuth /must/ be in the protected area
If you take a look at the first condition:
+ if (aRequest.getRequestURI().startsWith(protectedPath)
+ && !aRequest.getRequestURI().startsWith(redirectAfterAuth)
+ && !aRequest.getRequestURI().startsWith(
+ "/j_security_check", 10)) {
Basically it says:
- Only URLs are handled being in my protected area
- the URL must /not/ be equal my default protected starting-URL
- the URL requested must /not/ be j_security_check
The two latter conditions are necessary to avoid an infinite loop when
accessing protected content
> 2. Why do you check to see if the request URI /startsWith/ the
> redirectAfterAuth instead of being equal to it?
Because there might be some parameters after the adress in the URL -
i.e., if Cookies are not possible so that the session-information is
stored within the URL
> 3. Why are you checking to see if characters 10 - 16 of the request URI
> are "y_check". Why not check for the whole "j_security_check" string?
> Why not check the /end/ of the request URI for j_security_check,
> since the URI for j_security_check is not required to be
> /j_security_check but pretty much */j_security_check?
You are right with this:
Actually I made a mistake here:
When "j_security_check" is triggered, the URL will look like
/protected/j_security_check
As you can see, in this example it works since "/protected" is exactly
10 characters long.
Therefore, the correct code would be
+ && !aRequest.getRequestURI().startsWith(
+ "/j_security_check", protectedPath.length())) {
I'll correct that with a new patch during the weekend.
Why do I not ask for the String ending with "j_security_check"?
I was not sure how that URL looks like if session-info is encoded
within the URL - therefore I'm using startsWith()
> 4. Why are killing the session if the authtype is null?
Because we experienced with some users, esp. behind company-proxies,
that situations may occur where a session still exists, but the
Principal was null.
Therefore, if Principal is null, better be safe than sorry and make
sure you definately have a new session
> 5. Why does your valve pass-through any requests before the component
> has "started"? Is there a valid use case where NOT performing these
> checks and redirects is appropriate?
Nope. I took this code from AccessLogValve (I believe it was that
one), and my assumption was those checks don't make sense /before/ the
Valve is completely set (started).
If you feel that a different approach does make more sense here, I'm
happy for your suggestions
>
> It appears that your valve does nothing but murder the session and
> redirect the user if authtype=null and you are requesting a resource
> from a particular URI space. This does not seem particularly useful.
>
> Maybe I'm missing something subtle.
>
Seems to be - see my explanations on top.
Cheers
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available
@ http://pgpkeys.pca.dfn.de:11371
@ http://pgp.mit.edu:11371/
skype:rc46fi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 5/6/2009 2:56 PM, Gregor Schneider wrote:
> I've suggested a patch to issues.apache.org which might be helpful if
> Sid wants to implement his own Valve.
>
> My patch is a new valve, which diverts the call to a pre-defined URL
> if j_security_check is called (I had to circumvent the fact that after
> j_security_check Tomcat is always forwarding to the last request being
> stored - that doesn't work when dealing i.e. with frames.
I'm confused about some of your code (please forgive any formatting
problems):
> + if (started) {
> +
> + [SNIPPED debug statements]
> +
> + if (aRequest.getRequestURI().startsWith(protectedPath)
> + && !aRequest.getRequestURI().startsWith(redirectAfterAuth)
> + && !aRequest.getRequestURI().startsWith(
> + "/j_security_check", 10)) {
> + if (aRequest.getAuthType() == null) {
> + aRequest.getSession().invalidate();
> + aResponse.sendRedirect(redirectAfterAuth);
> + } else {
> + if (nextValve != null) {
> + nextValve.invoke(aRequest, aResponse);
> + }
> + }
> + } else {
> + if (nextValve != null) {
> + nextValve.invoke(aRequest, aResponse);
> + }
> + }
> + } else {
> + log.debug("LoginValve starting");
> + if (nextValve != null) {
> + getNext().invoke(aRequest, aResponse);
> + }
> + }
A few questions:
1. Why can't the "redirectAfterAuth" path be within the protected space?
2. Why do you check to see if the request URI /startsWith/ the
redirectAfterAuth instead of being equal to it?
3. Why are you checking to see if characters 10 - 16 of the request URI
are "y_check". Why not check for the whole "j_security_check" string?
Why not check the /end/ of the request URI for j_security_check,
since the URI for j_security_check is not required to be
/j_security_check but pretty much */j_security_check?
4. Why are killing the session if the authtype is null?
5. Why does your valve pass-through any requests before the component
has "started"? Is there a valid use case where NOT performing these
checks and redirects is appropriate?
It appears that your valve does nothing but murder the session and
redirect the user if authtype=null and you are requesting a resource
from a particular URI space. This does not seem particularly useful.
Maybe I'm missing something subtle.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoCQmEACgkQ9CaO5/Lv0PAuRwCdFUK6/DCK29UonliRDAY97Gu3
TLEAn0KpNqaJseJTOapk9kl7qrUVIqTS
=41Y+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Gregor Schneider <rc...@googlemail.com>.
I've suggested a patch to issues.apache.org which might be helpful if
Sid wants to implement his own Valve.
My patch is a new valve, which diverts the call to a pre-defined URL
if j_security_check is called (I had to circumvent the fact that after
j_security_check Tomcat is always forwarding to the last request being
stored - that doesn't work when dealing i.e. with frames.
The benefit for the OP:
Since it's a Valve, it's pretty easy to evaluate the url originally
requested - not sure, if the parameters are in there but I believe so.
Since this Valve is pretty straight forward and lean, it shouldn't be
a problem to adapt it so that it might meet Sid's needs.
You can find the patch here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46902
Cheers
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available
@ http://pgpkeys.pca.dfn.de:11371
@ http://pgp.mit.edu:11371/
skype:rc46fi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sid,
On 5/4/2009 5:45 PM, Sid Sidney wrote:
> Our application serves many different clients. Every page in our application (including the login.jsp and errorLogin.jsp) is configured to look like our clients predetermined look and feel. We use this property to distinguish which look and feel to display.
Could this be done with a URL path change instead of request parameters?
I realize that this means a big change to the way you are doing things,
but presumably you have a centralized "modify URL to encode LAF" and
"read LAF from URL" methods, so you could just change those to use paths
instead of parameters. Just a thought.
I've never seen private labeling done using request parameters before.
You can feel free to log a bug against TC 6. I'm just not sure how much
interest you'll get. You never know :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoAOvoACgkQ9CaO5/Lv0PDhFACbBv+dNvtYWI050CsYyAcKgqKJ
1+wAoJ2X1lZxUhCXpwZtG44GJzSSpfEz
=ZtBn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Sid Sidney <pv...@yahoo.com>.
Our application serves many different clients. Every page in our application (including the login.jsp and errorLogin.jsp) is configured to look like our clients predetermined look and feel. We use this property to distinguish which look and feel to display.
--- On Mon, 5/4/09, Christopher Schultz <ch...@christopherschultz.net> wrote:
From: Christopher Schultz <ch...@christopherschultz.net>
Subject: Re: How to make request parameters available to a login.jsp?
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Monday, May 4, 2009, 5:04 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sid,
On 5/4/2009 9:26 AM, Sid Sidney wrote:
> The secured resources are requested from an external page like this:
>
> <form method="post"
action="http://localhost:8080/testApp/secured/userHome.do"
name="userHomeForm">
> <input type="hidden" name="mydata"
value="MYDATA"/>
> <input type="submit" value="Enter Here"/>
> </form>
>
> This my login.jsp.
Perhaps if you tell us what you're really trying to accomplish, we could
help you do it another way. I doubt very much that there's a business
requirement to provide access to a request parameter in a login page.
So, what's the /real/ business requirement?
> The values are always null when the requests are made
> via a "post". However, this works when the request is made via a
"get".
I would guess that Tomcat is reading the request body into a buffer for
storage, but not bothering to make a copy of the parameters available to
the login page.
The spec isn't clear on this issue (making request parameters available
to the login page) so I'm pretty sure you'll get a less-than-warm
response to making this change to Tomcat. You can try, though. Patches,
as they say, are always welcome.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkn/WGwACgkQ9CaO5/Lv0PAGxwCcCNE4M18j8Rdpxgd6fmX9+UQi
NWMAoLH0XSFUYQ9GQ3b/DrRhpgXgfYa+
=TFpX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to make request parameters available to a login.jsp?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sid,
On 5/4/2009 9:26 AM, Sid Sidney wrote:
> The secured resources are requested from an external page like this:
>
> <form method="post" action="http://localhost:8080/testApp/secured/userHome.do" name="userHomeForm">
> <input type="hidden" name="mydata" value="MYDATA"/>
> <input type="submit" value="Enter Here"/>
> </form>
>
> This my login.jsp.
Perhaps if you tell us what you're really trying to accomplish, we could
help you do it another way. I doubt very much that there's a business
requirement to provide access to a request parameter in a login page.
So, what's the /real/ business requirement?
> The values are always null when the requests are made
> via a "post". However, this works when the request is made via a "get".
I would guess that Tomcat is reading the request body into a buffer for
storage, but not bothering to make a copy of the parameters available to
the login page.
The spec isn't clear on this issue (making request parameters available
to the login page) so I'm pretty sure you'll get a less-than-warm
response to making this change to Tomcat. You can try, though. Patches,
as they say, are always welcome.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkn/WGwACgkQ9CaO5/Lv0PAGxwCcCNE4M18j8Rdpxgd6fmX9+UQi
NWMAoLH0XSFUYQ9GQ3b/DrRhpgXgfYa+
=TFpX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to make request parameters available to a login.jsp?
Posted by Sid Sidney <pv...@yahoo.com>.
What should I be looking in the ActionServlet.java??? Since control is not here yet? I'm not trying to be rude, but not sure how that would help. The same problem happens when I request a jsp file.
--- On Mon, 5/4/09, Martin Gainty <mg...@hotmail.com> wrote:
From: Martin Gainty <mg...@hotmail.com>
Subject: RE: How to make request parameters available to a login.jsp?
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Monday, May 4, 2009, 11:20 AM
can we see doGet and doPost for ActionServlet.java
thanks
Martin
______________________________________________
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note de
déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then
we ask politely to report. Each unauthorized forwarding or manufacturing of a
copy is inadmissible. This message serves only for the exchange of information
and has no legal binding effect. Due to the easy manipulation of emails we
cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
le destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
copie de ceci est interdite. Ce message sert à l'information seulement et
n'aura pas n'importe quel effet légalement obligatoire. Étant donné
que les email peuvent facilement être sujets à la manipulation, nous ne
pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Mon, 4 May 2009 06:26:47 -0700
> From: pvcsvmux@yahoo.com
> Subject: How to make request parameters available to a login.jsp?
> To: users@tomcat.apache.org
>
> Hi, I have posted this question in many different forum, but I still have
not found an answer. Perhaps, I will in this list.
>
> I have a secured resource in Tomcat.
> My resources are secured via FORM authentication (j_security_check).
> The secured resources are requested from an external page like this:
>
> <form method="post"
action="http://localhost:8080/testApp/secured/userHome.do"
name="userHomeForm">
> <input type="hidden" name="mydata"
value="MYDATA"/>
> <input type="submit" value="Enter Here"/>
> </form>
>
> This my login.jsp. I have a business requirement that needs to access the
"mydata" request parameter from this page.
>
> The values are always null when the requests are made
> via a "post". However, this works when the request is made via a
"get" I
> cannot change my forms to "get" method that is just not
possible. If anyone has any
> idea what we need to do, please please help us out. Thanks in advance!
This works in Tomcat 5.0. But not in the newer releases. And we need to move to
a newer release.
>
> (I did not paste my entire login.jsp. But I can added if requested) Thanks
in advance.
>
> <%
> request.setCharacterEncoding("UTF-
>
> java.util.Enumeration paramNames = request.getParameterNames();
>
> out.println("<p>My Param Names Enum:</p>");
> while(paramNames.hasMoreElements()) {
> out.println("<p>Param Name: " +
paramNames.nextElement() + "</p>");
> }
>
> String consignmentId = request.getParameter( "mydata" );
> out.println("<p>My Data: " + consignmentId +
"</p>");
> %>
>
> <form method="post" action='<%=
response.encodeURL("j_security_check") %>' >
> <table border="0" >
> <tr>
> <th >Username:</th>
> <td ><input type="text"
name="j_username"></td>
> </tr>
>
>
>
>
>
>
>
>
_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009
RE: How to make request parameters available to a login.jsp?
Posted by Martin Gainty <mg...@hotmail.com>.
can we see doGet and doPost for ActionServlet.java
thanks
Martin
______________________________________________
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note de déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Mon, 4 May 2009 06:26:47 -0700
> From: pvcsvmux@yahoo.com
> Subject: How to make request parameters available to a login.jsp?
> To: users@tomcat.apache.org
>
> Hi, I have posted this question in many different forum, but I still have not found an answer. Perhaps, I will in this list.
>
> I have a secured resource in Tomcat.
> My resources are secured via FORM authentication (j_security_check).
> The secured resources are requested from an external page like this:
>
> <form method="post" action="http://localhost:8080/testApp/secured/userHome.do" name="userHomeForm">
> <input type="hidden" name="mydata" value="MYDATA"/>
> <input type="submit" value="Enter Here"/>
> </form>
>
> This my login.jsp. I have a business requirement that needs to access the "mydata" request parameter from this page.
>
> The values are always null when the requests are made
> via a "post". However, this works when the request is made via a "get" I
> cannot change my forms to "get" method that is just not possible. If anyone has any
> idea what we need to do, please please help us out. Thanks in advance! This works in Tomcat 5.0. But not in the newer releases. And we need to move to a newer release.
>
> (I did not paste my entire login.jsp. But I can added if requested) Thanks in advance.
>
> <%
> request.setCharacterEncoding("UTF-
>
> java.util.Enumeration paramNames = request.getParameterNames();
>
> out.println("<p>My Param Names Enum:</p>");
> while(paramNames.hasMoreElements()) {
> out.println("<p>Param Name: " + paramNames.nextElement() + "</p>");
> }
>
> String consignmentId = request.getParameter( "mydata" );
> out.println("<p>My Data: " + consignmentId + "</p>");
> %>
>
> <form method="post" action='<%= response.encodeURL("j_security_check") %>' >
> <table border="0" >
> <tr>
> <th >Username:</th>
> <td ><input type="text" name="j_username"></td>
> </tr>
>
>
>
>
>
>
>
>
_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009