Problem with tomcat 6.0.32

[ruds]

hi,
I'm am deploying an application having JSP's and few servlets. My servlet is not getting invoked after calling from JSP. My web.xml entry is:
<web-app>
<servlet>
<servlet-name>login</servlet-name>
<servlet-class>CheckLogin</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>login</servlet-name>
<url-pattern>/CheckLogin/* </url-pattern>
</servlet-mapping>
</web-app>

all my classes are in the WEB-INF/classes directory. On called by JSP I'm getting error as:
The requested resource (/CheckLogin) is not available.
I'm calling this from a JSP form element:
<FORM name="f1" ACTION="/CheckLogin" METHOD=POST onsubmit='return checkall()'>

please tell what might be causing this problem.
Thanks in advance.

 

[markspace]

hi,
I'm am deploying an application having JSP's and few servlets. My servlet is not getting invoked after calling from JSP. My web.xml entry is:
<web-app>
<servlet>
<servlet-name>login</servlet-name>
<servlet-class>CheckLogin</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>login</servlet-name>
<url-pattern>/CheckLogin/* </url-pattern>
</servlet-mapping>
</web-app>

all my classes are in the WEB-INF/classes directory. On called by JSP I'm getting error as:
The requested resource (/CheckLogin) is not available.
I'm calling this from a JSP form element:
<FORM name="f1" ACTION="/CheckLogin" METHOD=POST onsubmit='return checkall()'>

please tell what might be causing this problem.

What is the context path for the web app? Can you show us the URL used
for the FORM above, and the URL of the /CheckLogin action that doesn't
work? Just cut and paste them both from the browser, don't try to
"figure them out." I want the host name too, even if it's "127.0.0.1"
or localhost.

 

[ruds]

the URL for my webapp is: http://localhost:8080/FIR/login.jsp
the URL which it gets directed to should be: http://localhost:8080/FIR/CheckLogin
but it is going at: http://localhost:8080/CheckLogin

 

[Fredrik Jonson]

I'm am deploying an application having JSP's and few servlets. My servlet is
not getting invoked after calling from JSP. My web.xml entry is:

<servlet-mapping>
<servlet-name>login</servlet-name>
<url-pattern>/CheckLogin/* </url-pattern>
</servlet-mapping>

I'm calling this from a JSP form element:
<FORM name="f1" ACTION="/CheckLogin" METHOD=POST onsubmit='return checkall()'>

You need to prepend the servlet context path to the form action url.

In html, when you specify a relative url that starts with a / it is
interpered as being relative to the server root. So /foo is interpreted
as http://example.com/foo. The servlet mapping in web.xml does normally
not start from the server root, but from the servlet context path.

 

[markspace]

the URL for my webapp is: http://localhost:8080/FIR/login.jsp
the URL which it gets directed to should be: http://localhost:8080/FIR/CheckLogin
but it is going at: http://localhost:8080/CheckLogin

Yup, c.f. Fredrik's reply: the "action" from the form needs to either be
/FIR/CheckLogin, or it needs to be a relative URL -- "CheckLogin" with
no slash in front.

Your missing the context path, in other words, which is easy for newbies
to trip on.

 

[Arne Vajhøj]

You need to prepend the servlet context path to the form action url.

Or drop thw / entirely.

In html, when you specify a relative url that starts with a / it is
interpered as being relative to the server root. So /foo is interpreted
as http://example.com/foo. The servlet mapping in web.xml does normally
not start from the server root, but from the servlet context path.

That is almost certainly the problem.

But may I use the opportunity to mention that it should not be:

action="CheckLogin"

but:

action="<%=response.encodeURL("CheckLogin")%>"

to work with cookies disabled.

Something that is often forgotten today.

An even better solution would probably be to use a taglib that
handles all that stuff for one, but then we are somewhat changing
topic.

Arne

 

[markspace]

action="<%=response.encodeURL("CheckLogin")%>"

to work with cookies disabled.

Something that is often forgotten today.

Huh, I must be missing something. "CheckLogin" is a hard-coded string
that plainly needs no encoding. What is it that I don't see?

 

[Arne Vajhøj]

Huh, I must be missing something. "CheckLogin" is a hard-coded string
that plainly needs no encoding. What is it that I don't see?

That encodeURL adds the session id to the URL if the browser
does not support cookies (or if it is unknown whether it support
cookies).

Arne

 

[Arne Vajhøj]

That encodeURL adds the session id to the URL if the browser
does not support cookies (or if it is unknown whether it support
cookies).

It is well documented:

http://docs.oracle.com/javaee/6/api...vletResponse.html#encodeURL(java.lang.String)

but the cookies disabled scenario is not much on the radar
screen today.

Arne

 

[markspace]

That encodeURL adds the session id to the URL if the browser
does not support cookies (or if it is unknown whether it support
cookies).

Ah right, I knew that, but I haven't used JSPs in so long I'd forgotten
it. Thanks!

 

[Arne Vajhøj]

Ah right, I knew that, but I haven't used JSPs in so long I'd forgotten
it.

I suspect that even some having done JSP's recently may have forgotten.

Arne

 

[Andreas Leitgeb]

I suspect that even some having done JSP's recently may have forgotten.

I know of a case, where the encodeURL was actually removed.

Some security-guys barfed on the session-id in the url-string.
They called it unsafe, for allowing easy session-takeover. (not
sure about the exact attack-vector they actually had in mind.)

Is that still an issue? Probably, the "secure" way is to
pass the sessionId as a plain parameter in an https-POST
request, or as a cookie in any of https-GET or https-POST.

What's current state of the art?

Does it matter for plain http, whether the jsessionId is
in the URL or in the still unencrypted other data? Surely
not for network-sniffers, but maybe it makes a difference
for simpler attacks?

 

[Arne Vajhøj]

I know of a case, where the encodeURL was actually removed.

Some security-guys barfed on the session-id in the url-string.
They called it unsafe, for allowing easy session-takeover. (not
sure about the exact attack-vector they actually had in mind.)

Is that still an issue? Probably, the "secure" way is to
pass the sessionId as a plain parameter in an https-POST
request, or as a cookie in any of https-GET or https-POST.

What's current state of the art?

Does it matter for plain http, whether the jsessionId is
in the URL or in the still unencrypted other data? Surely
not for network-sniffers, but maybe it makes a difference
for simpler attacks?

I don't see it as a big security concern.

But sessions cookies are generally considered more secure
than URL rewriting.

I believe the concerns are that URL rewriting causes the
session id to end up in:
- server log files
- browser history
and practically nobody logs out explicitly, so the session id
will be valid N minutes after the user has stopped using the
web app.

To me that is not super critical problems, but YMMV.

Arne