redirected to random file in webapp root instead of desired page

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

redirected to random file in webapp root instead of desired page

Noel Bush-2
I have successfully gotten JAAS to work, with one small annoyance.  This
is how it goes:

1.  I start my app
2.  I point my browser to any URL in the app (as configured in web.xml)
3.  I get my login.html, but the stylesheet it uses has not been loaded
4.  I enter my username and password and submit
5.  Instead of getting the original requested page, I get a file from
the webapp root, apparently selected at random.  Sometimes I get
"favicon.ico", other times one of my stylesheets.  It does seem that the
file selected is always one that is referenced by the login html page.
6.  If I now "fix" the URL, I get sent to the login page and can log in
and get the right page again.

Any idea what could be wrong?

TIA,
Noel


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: redirected to random file in webapp root instead of desired page

Noel Bush-2
Is there no hope for me?  Seems like a pretty fundamental sort of error.
  Surely everybody doesn't have this issue.....

Noel Bush wrote:

> I have successfully gotten JAAS to work, with one small annoyance.  This
> is how it goes:
>
> 1.  I start my app
> 2.  I point my browser to any URL in the app (as configured in web.xml)
> 3.  I get my login.html, but the stylesheet it uses has not been loaded
> 4.  I enter my username and password and submit
> 5.  Instead of getting the original requested page, I get a file from
> the webapp root, apparently selected at random.  Sometimes I get
> "favicon.ico", other times one of my stylesheets.  It does seem that the
> file selected is always one that is referenced by the login html page.
> 6.  If I now "fix" the URL, I get sent to the login page and can log in
> and get the right page again.
>
> Any idea what could be wrong?
>
> TIA,
> Noel
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: redirected to random file in webapp root instead of desired page

Chris Haynes
No, I don't know of anybody else having that issue ;-))

What authentication method are you using?  BASIC?

I presume your browser is a standard production one.  Do you have the identical
problem with other makes of browser?

It reads to me like the requirement to authenticate is not kicking-in until
after the browser has fetched the first page. In other words, the server has
been configured so that no login is required to get the HTML of the first page,
but any follow-up content (favicon, style sheet, embedded graphics etc. ) are
hitting the need to log in. I suspect the browser is then getting confused, and
losing track of what it was doing when it hit the need to log in at this phase
in the process.

I suggest you check your security configuration and check that the need to log
in is being triggered while making the very first request for the HTML of the
opening page.

HTH

Chris Haynes


 "Noel Bush" agonized:

> Is there no hope for me?  Seems like a pretty fundamental sort of error.
>  Surely everybody doesn't have this issue.....
>
> Noel Bush wrote:
>> I have successfully gotten JAAS to work, with one small annoyance.  This is
>> how it goes:
>>
>> 1.  I start my app
>> 2.  I point my browser to any URL in the app (as configured in web.xml)
>> 3.  I get my login.html, but the stylesheet it uses has not been loaded
>> 4.  I enter my username and password and submit
>> 5.  Instead of getting the original requested page, I get a file from the
>> webapp root, apparently selected at random.  Sometimes I get "favicon.ico",
>> other times one of my stylesheets.  It does seem that the file selected is
>> always one that is referenced by the login html page.
>> 6.  If I now "fix" the URL, I get sent to the login page and can log in and
>> get the right page again.
>>
>> Any idea what could be wrong?
>>
>> TIA,
>> Noel




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: redirected to random file in webapp root instead of desired page

Noel Bush-2
I am using FORM authentication.  The browser is Firefox 1.0.4.

What you are saying makes sense to me -- but then it also seems to
suggest that my login page *cannot* use a style sheet, embedded
graphics, etc. -- or else, all these items have to be kept in some
separate "compartment" that never requires log in.

Or what am I missing?

Here is the relevant (I hope) snippet of my web.xml:

   <security-constraint>
     <web-resource-collection>
       <web-resource-name>My Application</web-resource-name>
       <url-pattern>/</url-pattern>
     </web-resource-collection>
     <auth-constraint>
       <role-name>User</role-name>
       <role-name>Administrator</role-name>
     </auth-constraint>
   </security-constraint>
   <login-config>
     <auth-method>FORM</auth-method>
     <realm-name>My Application</realm-name>
     <form-login-config>
       <form-login-page>/login.html </form-login-page>
       <form-error-page>/error401.html </form-error-page>
     </form-login-config>
   </login-config>

The login.html file is in the root webapp directory, along with the
stylesheet (and favicon for that matter).  Do I need to set things up
differently?

Thanks,
Noel

Chris Haynes counseled:

> No, I don't know of anybody else having that issue ;-))
>
> What authentication method are you using?  BASIC?
>
> I presume your browser is a standard production one.  Do you have the
> identical problem with other makes of browser?
>
> It reads to me like the requirement to authenticate is not kicking-in
> until after the browser has fetched the first page. In other words, the
> server has been configured so that no login is required to get the HTML
> of the first page, but any follow-up content (favicon, style sheet,
> embedded graphics etc. ) are hitting the need to log in. I suspect the
> browser is then getting confused, and losing track of what it was doing
> when it hit the need to log in at this phase in the process.
>
> I suggest you check your security configuration and check that the need
> to log in is being triggered while making the very first request for the
> HTML of the opening page.
>
> HTH
>
> Chris Haynes
>
>
> "Noel Bush" agonized:
>
>> Is there no hope for me?  Seems like a pretty fundamental sort of error.
>>  Surely everybody doesn't have this issue.....
>>
>> Noel Bush wrote:
>>
>>> I have successfully gotten JAAS to work, with one small annoyance.  
>>> This is how it goes:
>>>
>>> 1.  I start my app
>>> 2.  I point my browser to any URL in the app (as configured in web.xml)
>>> 3.  I get my login.html, but the stylesheet it uses has not been loaded
>>> 4.  I enter my username and password and submit
>>> 5.  Instead of getting the original requested page, I get a file from
>>> the webapp root, apparently selected at random.  Sometimes I get
>>> "favicon.ico", other times one of my stylesheets.  It does seem that
>>> the file selected is always one that is referenced by the login html
>>> page.
>>> 6.  If I now "fix" the URL, I get sent to the login page and can log
>>> in and get the right page again.
>>>
>>> Any idea what could be wrong?
>>>
>>> TIA,
>>> Noel
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: redirected to random file in webapp root instead of desired page

Chris Haynes
Noel:

I found this advice from Lief Mortenson  (jetty-discuss 15 Dec 2004)...
-----------------------------

The problem is that the request for the /favicon.ico file is itself
triggering a request
for user login.  Once you login, Jetty goes on to attempt to display the
file that
you had originally requested.  In this case that is the favicon.ico
file, which does
not exist.

To fix this, you need to tell Jetty not to protect that file.  You will
want to do the
same thing for any other files that should not require the user to be
logged in.
For example if you display any images on the login page while using FORM
authentication.

    <security-constraint>
        <display-name>Public area</display-name>
        <web-resource-collection>
            <web-resource-name>Public area</web-resource-name>
            <url-pattern>/favicon.ico</url-pattern>
            <url-pattern>/pubimages/*</url-pattern>
            <http-method>GET</http-method>
        </web-resource-collection>

<user-data-constraint><transport-guarantee>NONE</transport-guarantee></user-data-constraint>
    </security-constraint>

-----------------------------------------------

If that doesn't help, and SSL is involved, you might like to look in the
jetty-discuss and then jetty-support archives at the exchange of eMails between
DE BENEDICTIS DAVIDE <[hidden email]> and myself  starting 11 Dec 2004.



Chris

----- Original Message -----
From: "Noel Bush" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, July 21, 2005 1:44 AM
Subject: Re: [jetty-discuss] redirected to random file in webapp root instead of
desired page


>I am using FORM authentication.  The browser is Firefox 1.0.4.
>
> What you are saying makes sense to me -- but then it also seems to suggest
> that my login page *cannot* use a style sheet, embedded graphics, etc. -- or
> else, all these items have to be kept in some separate "compartment" that
> never requires log in.
>
> Or what am I missing?
>
> Here is the relevant (I hope) snippet of my web.xml:
>
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>My Application</web-resource-name>
>       <url-pattern>/</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>       <role-name>User</role-name>
>       <role-name>Administrator</role-name>
>     </auth-constraint>
>   </security-constraint>
>   <login-config>
>     <auth-method>FORM</auth-method>
>     <realm-name>My Application</realm-name>
>     <form-login-config>
>       <form-login-page>/login.html </form-login-page>
>       <form-error-page>/error401.html </form-error-page>
>     </form-login-config>
>   </login-config>
>
> The login.html file is in the root webapp directory, along with the stylesheet
> (and favicon for that matter).  Do I need to set things up differently?
>
> Thanks,
> Noel
>
> Chris Haynes counseled:
>> No, I don't know of anybody else having that issue ;-))
>>
>> What authentication method are you using?  BASIC?
>>
>> I presume your browser is a standard production one.  Do you have the
>> identical problem with other makes of browser?
>>
>> It reads to me like the requirement to authenticate is not kicking-in until
>> after the browser has fetched the first page. In other words, the server has
>> been configured so that no login is required to get the HTML of the first
>> page, but any follow-up content (favicon, style sheet, embedded graphics
>> etc. ) are hitting the need to log in. I suspect the browser is then getting
>> confused, and losing track of what it was doing when it hit the need to log
>> in at this phase in the process.
>>
>> I suggest you check your security configuration and check that the need to
>> log in is being triggered while making the very first request for the HTML of
>> the opening page.
>>
>> HTH
>>
>> Chris Haynes
>>
>>
>> "Noel Bush" agonized:
>>
>>> Is there no hope for me?  Seems like a pretty fundamental sort of error.
>>>  Surely everybody doesn't have this issue.....
>>>
>>> Noel Bush wrote:
>>>
>>>> I have successfully gotten JAAS to work, with one small annoyance.  This is
>>>> how it goes:
>>>>
>>>> 1.  I start my app
>>>> 2.  I point my browser to any URL in the app (as configured in web.xml)
>>>> 3.  I get my login.html, but the stylesheet it uses has not been loaded
>>>> 4.  I enter my username and password and submit
>>>> 5.  Instead of getting the original requested page, I get a file from the
>>>> webapp root, apparently selected at random.  Sometimes I get "favicon.ico",
>>>> other times one of my stylesheets.  It does seem that the file selected is
>>>> always one that is referenced by the login html page.
>>>> 6.  If I now "fix" the URL, I get sent to the login page and can log in and
>>>> get the right page again.
>>>>
>>>> Any idea what could be wrong?
>>>>
>>>> TIA,
>>>> Noel
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> jetty-discuss mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: redirected to random file in webapp root instead of desired page

Noel Bush-2
That's perfect.  I followed this advice and it solved the problem right
away.  Thanks!

Chris Haynes wrote:

> Noel:
>
> I found this advice from Lief Mortenson  (jetty-discuss 15 Dec 2004)...
> -----------------------------
>
> The problem is that the request for the /favicon.ico file is itself
> triggering a request
> for user login.  Once you login, Jetty goes on to attempt to display the
> file that
> you had originally requested.  In this case that is the favicon.ico
> file, which does
> not exist.
>
> To fix this, you need to tell Jetty not to protect that file.  You will
> want to do the
> same thing for any other files that should not require the user to be
> logged in.
> For example if you display any images on the login page while using FORM
> authentication.
>
>    <security-constraint>
>        <display-name>Public area</display-name>
>        <web-resource-collection>
>            <web-resource-name>Public area</web-resource-name>
>            <url-pattern>/favicon.ico</url-pattern>
>            <url-pattern>/pubimages/*</url-pattern>
>            <http-method>GET</http-method>
>        </web-resource-collection>
>
> <user-data-constraint><transport-guarantee>NONE</transport-guarantee></user-data-constraint>
>
>    </security-constraint>
>
> -----------------------------------------------
>
> If that doesn't help, and SSL is involved, you might like to look in the
> jetty-discuss and then jetty-support archives at the exchange of eMails
> between DE BENEDICTIS DAVIDE <[hidden email]> and myself  
> starting 11 Dec 2004.
>
>
>
> Chris
>
> ----- Original Message ----- From: "Noel Bush" <[hidden email]>
> To: <[hidden email]>
> Sent: Thursday, July 21, 2005 1:44 AM
> Subject: Re: [jetty-discuss] redirected to random file in webapp root
> instead of desired page
>
>
>> I am using FORM authentication.  The browser is Firefox 1.0.4.
>>
>> What you are saying makes sense to me -- but then it also seems to
>> suggest that my login page *cannot* use a style sheet, embedded
>> graphics, etc. -- or else, all these items have to be kept in some
>> separate "compartment" that never requires log in.
>>
>> Or what am I missing?
>>
>> Here is the relevant (I hope) snippet of my web.xml:
>>
>>   <security-constraint>
>>     <web-resource-collection>
>>       <web-resource-name>My Application</web-resource-name>
>>       <url-pattern>/</url-pattern>
>>     </web-resource-collection>
>>     <auth-constraint>
>>       <role-name>User</role-name>
>>       <role-name>Administrator</role-name>
>>     </auth-constraint>
>>   </security-constraint>
>>   <login-config>
>>     <auth-method>FORM</auth-method>
>>     <realm-name>My Application</realm-name>
>>     <form-login-config>
>>       <form-login-page>/login.html </form-login-page>
>>       <form-error-page>/error401.html </form-error-page>
>>     </form-login-config>
>>   </login-config>
>>
>> The login.html file is in the root webapp directory, along with the
>> stylesheet (and favicon for that matter).  Do I need to set things up
>> differently?
>>
>> Thanks,
>> Noel
>>
>> Chris Haynes counseled:
>>
>>> No, I don't know of anybody else having that issue ;-))
>>>
>>> What authentication method are you using?  BASIC?
>>>
>>> I presume your browser is a standard production one.  Do you have the
>>> identical problem with other makes of browser?
>>>
>>> It reads to me like the requirement to authenticate is not kicking-in
>>> until after the browser has fetched the first page. In other words,
>>> the server has been configured so that no login is required to get
>>> the HTML of the first page, but any follow-up content (favicon, style
>>> sheet, embedded graphics etc. ) are hitting the need to log in. I
>>> suspect the browser is then getting confused, and losing track of
>>> what it was doing when it hit the need to log in at this phase in the
>>> process.
>>>
>>> I suggest you check your security configuration and check that the
>>> need to log in is being triggered while making the very first request
>>> for the HTML of the opening page.
>>>
>>> HTH
>>>
>>> Chris Haynes
>>>
>>>
>>> "Noel Bush" agonized:
>>>
>>>> Is there no hope for me?  Seems like a pretty fundamental sort of
>>>> error.
>>>>  Surely everybody doesn't have this issue.....
>>>>
>>>> Noel Bush wrote:
>>>>
>>>>> I have successfully gotten JAAS to work, with one small annoyance.  
>>>>> This is how it goes:
>>>>>
>>>>> 1.  I start my app
>>>>> 2.  I point my browser to any URL in the app (as configured in
>>>>> web.xml)
>>>>> 3.  I get my login.html, but the stylesheet it uses has not been
>>>>> loaded
>>>>> 4.  I enter my username and password and submit
>>>>> 5.  Instead of getting the original requested page, I get a file
>>>>> from the webapp root, apparently selected at random.  Sometimes I
>>>>> get "favicon.ico", other times one of my stylesheets.  It does seem
>>>>> that the file selected is always one that is referenced by the
>>>>> login html page.
>>>>> 6.  If I now "fix" the URL, I get sent to the login page and can
>>>>> log in and get the right page again.
>>>>>
>>>>> Any idea what could be wrong?
>>>>>
>>>>> TIA,
>>>>> Noel
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>> informative Webcasts and more! Get everything you need to get up to
>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>> _______________________________________________
>>> jetty-discuss mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> jetty-discuss mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>
>>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Odd Warning (Part 2)

Tony Seebregts
In reply to this post by Chris Haynes
Hi Greg,

Follow-up to the earlier mail about the Bad Request-Missing Content
warning.

Having worked through the logic it seems that a redirect from a servlet
commits the HttpResponse - and in the commit() method the input stream
Expect-Continue flag is cleared. HttpConnection handleNext() then tries
to cleanup the connection and because the Expect-Continue flag that was
there is now cleared, tries to read from a 'closed' InputStream.

I have a temporary workaround which involves setting an additional
pendingExpectContinue flag, but its a huge kluge :-( . Think there might
be a cleaner way to handle it.

regards

Tony Seebregts



> FYI, I'm getting an odd warning with redirects and authentication
> failures:
>
> WARN  [SocketListener0-1] org.mortbay.http.HttpConnection - POST
> /cibecs/test HTTP/1.1 HttpException(400,Bad Request,Missing Content).
>
> Its generated at line 1029 in HttpConnection.
>




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss