Problem with tomcat 6.0.32

Discussion in 'Java' started by ruds, Sep 5, 2012.

  1. ruds

    ruds Guest

    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.
     
    ruds, Sep 5, 2012
    #1
    1. Advertising

  2. ruds

    markspace Guest

    On 9/4/2012 11:50 PM, ruds wrote:
    > 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.
     
    markspace, Sep 5, 2012
    #2
    1. Advertising

  3. ruds

    ruds Guest

    ruds, Sep 6, 2012
    #3
  4. In <> ruds wrote:

    > 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.

    --
    Fredrik Jonson
     
    Fredrik Jonson, Sep 6, 2012
    #4
  5. ruds

    markspace Guest

    markspace, Sep 6, 2012
    #5
  6. ruds

    Arne Vajhøj Guest

    On 9/6/2012 12:36 AM, Fredrik Jonson wrote:
    > In <> ruds wrote:
    >
    >> 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.


    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
     
    Arne Vajhøj, Sep 9, 2012
    #6
  7. ruds

    markspace Guest

    On 9/8/2012 7:33 PM, Arne Vajhøj wrote:

    > 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?
     
    markspace, Sep 9, 2012
    #7
  8. ruds

    Arne Vajhøj Guest

    On 9/8/2012 11:22 PM, markspace wrote:
    > On 9/8/2012 7:33 PM, Arne Vajhøj wrote:
    >
    >> 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?


    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, Sep 9, 2012
    #8
  9. ruds

    Arne Vajhøj Guest

    On 9/8/2012 11:25 PM, Arne Vajhøj wrote:
    > On 9/8/2012 11:22 PM, markspace wrote:
    >> On 9/8/2012 7:33 PM, Arne Vajhøj wrote:
    >>
    >>> 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?

    >
    > 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
     
    Arne Vajhøj, Sep 9, 2012
    #9
  10. ruds

    markspace Guest

    On 9/8/2012 8:25 PM, Arne Vajhøj wrote:
    > On 9/8/2012 11:22 PM, markspace wrote:
    >> On 9/8/2012 7:33 PM, Arne Vajhøj wrote:
    >>
    >>> 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?

    >
    > 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!
     
    markspace, Sep 9, 2012
    #10
  11. ruds

    Arne Vajhøj Guest

    On 9/8/2012 11:36 PM, markspace wrote:
    > On 9/8/2012 8:25 PM, Arne Vajhøj wrote:
    >> On 9/8/2012 11:22 PM, markspace wrote:
    >>> On 9/8/2012 7:33 PM, Arne Vajhøj wrote:
    >>>
    >>>> 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?

    >>
    >> 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.


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

    Arne
     
    Arne Vajhøj, Sep 9, 2012
    #11
  12. jsessionId (was: Re: Problem with tomcat 6.0.32)

    Arne Vajhøj <> wrote:
    >>>>> action="<%=response.encodeURL("CheckLogin")%>"
    >>>>> to work with cookies disabled.

    > 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?
     
    Andreas Leitgeb, Sep 9, 2012
    #12
  13. Re: jsessionId

    On 9/9/2012 5:35 AM, Andreas Leitgeb wrote:
    > Arne Vajhøj <> wrote:
    >>>>>> action="<%=response.encodeURL("CheckLogin")%>"
    >>>>>> to work with cookies disabled.

    >> 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?


    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
     
    Arne Vajhøj, Sep 9, 2012
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. %=zerointeractive.it%

    [TOMCAT] Tomcat crashes

    %=zerointeractive.it%, Jan 22, 2004, in forum: Java
    Replies:
    1
    Views:
    440
    Erwin Moller
    Jan 22, 2004
  2. Christos Gravvanis
    Replies:
    0
    Views:
    2,075
    Christos Gravvanis
    Jul 7, 2004
  3. Rakesh Pandit
    Replies:
    0
    Views:
    519
    Rakesh Pandit
    Jul 12, 2005
  4. Marcin Cenkier
    Replies:
    1
    Views:
    5,485
    Marcin Cenkier
    Apr 12, 2006
  5. Andi
    Replies:
    5
    Views:
    1,360
Loading...

Share This Page