DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=3839


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|major   |enhancement
  Component|Webapps:Examples|Catalina
 OS/Version|Linux   |All
   Priority|P3  |P5
   Platform|PC  |All
Version|4.0 Final   |Nightly Build




--- Additional Comments From [EMAIL PROTECTED]  2004-12-24 18:00 ---
As has alreday been stated in this report, tomcat is spec compliant in this 
regard so I am marking this report as an enhancement request.

Given the lack of movement on this bug since it was raised, it is unlikely 
that anything will be done to address this enhancement unless someone wants to 
provide a patch.

I have also corrected a few other parameters on the original report.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|CLOSED  |REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2004-06-06 12:57 ---
First of all, I know that this FORM based authentication problem has been raised
many times, but I really think that I have come up with a solution that would
not violate the sun spec.

The key to solving this problem is not to expose the login page URL to the user
so it can't be bookmarked (the same goes for the error page URL).

First the current flow with form based authentication:
1. Call the protected resource. (this is where the user context is saved)
2. Automatic outer forward to the custom login page. (this is the place where
the users bookmark it)
3. Submit the login via j_security_check. (lets say the password was incorrect)
4. Automatic outer forward to the custom error page. (this page can also be
bookmarked)(the steps 3 and 4 can be repeated many times).
5. Submit the login via j_security_check. (lets say that everything was OK)
6. Restore the original URL, delete the user context and do an aotomatic outer
forward.

As everybody can see the problem lies in the outer forwards to the "must be
hidden" login and error page.

Now concider the next flow that uses inner forwards instead.
1. Call the protected resource. (this is where the user context is saved)
2. Inner forward to the custom login page so the original URL stays in the browser.
3. Submit the login via j_security_check. (lets say the password was incorrect
in which case we will save a marker to know that there was an error)
4. Now temporary recreate the original URL and do an automatic outer forward to
it. As we saved a marker we won't do an inner forward to the login page anymore
but to the error page. Additionally we delete the marker so that no other
request gets it.
5. Submit the login via j_security_check. (lets say that everything was OK)
6. Restore the original URL, delete the user context and do an aotomatic outer
forward.

This new proposed solution has only two weak spots but these are unsignificant ones.
1. If the user happens to preform another separate call to the same protected
resource in between the marker saveing and automatic outer forward returning
then the error page will go to the wrong window. I also think it's impossible to
happen in a real case.
2. The second problem is a bit bigger one. If the user will do a refresh to the
login error page he will be taken to the login page instead. Now this behaviour
would disturb me a lot if it weren't for the fact that usually you can't refresh
form submits either plus this kind of action could also be concidered as a new
request for the protected resource that it really is.

As I know you all are a bit like me and won't accept the second point too easely
because the fact remains that a refresh changes the users page. In that case
it's possible to leave the error page logic like it works right now and hope
that users don't want to bookmark error pages ;) (I myself think the refresh
problem to be to small to allow users to bookmark wrong pages).

Now I have just two more things to say.
1. If anybody thinks the marker can be preserved longer to fix the second
problem please stop. Because a new horrible problem will arise when the user
leaves our application without authorizeing and returns later to find an error
page staring in his face (sessions, with the help of cokies, last a long time).
2. If anybody finds error in my reasoning please let me know but I'm sure that
Tomcat can be the first web container to resolv this problem gracefully.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page





--- Additional Comments From [EMAIL PROTECTED]  2003-08-28 17:54 ---

There is a dirty hack way of solving this in TC4. I should probably be flogged in 
public for posting 
such a filthy hack, but anyway... I suspect it is not very portable.

In web.xml define an error page for 400 such as 'error400.jsp':
In that page do something along the lines of:

<%
String requestURI = (String)request.getAttribute( "javax.servlet.error.request_uri" );
boolean isLogin = requestURI.indexOf( "j_security_check" ) >= 0;

if ( isLogin ) {
String username = request.getParameter( "j_username" );
String password = request.getParameter( "j_password" );

session.setAttribute( "j_username", username );
session.setAttribute( "j_password", password );

response.sendRedirect( "/some/protected/resource" );
return;
}
%>
// display error message.




In the form based login page do something like:

<%
  // j_username and j_password may be set in the error400.jsp page on a 
  // direct reference to the j_security_check page.
  String username = (String)session.getAttribute( "j_username" );
  String password = (String)session.getAttribute( "j_password" );

  boolean autoLogin = username != null && password != null;

  if ( autoLogin ) {
session.removeAttribute( "j_username" );
session.removeAttribute( "j_password" );
%>

  


  

  
document.login.submit();
  

%>
// now let the browser auto submit the login.
return
  }
%>

//  Display your normal  login page.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page





--- Additional Comments From [EMAIL PROTECTED]  2002-06-14 15:10 ---
Yes I just discovered this myself: Mozilla 1.0 does not seem to send a referer
on a redirect so I got an infinite loop.  Furthermore some proxies can be set to
strip out the referer.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page





--- Additional Comments From [EMAIL PROTECTED]  2002-06-14 07:51 ---
That workaround is dangerous.
In some browsers (like Opera) referrer logging can be disabled, in which case
you have an endless loop...

Two other suggestions for a workaround (but probably non-portable):
- Test isNew() on the Session object. For form-based login, the container needs
to store the context of the original call somewhere.  I pretty sure that tomcat
uses the session object for this (though it will be hidden from the webapp)
- Put the login page itself in the protected area.  I believe Tomcat 4 allows
this.  In the login page you can then put code to test if the user is already
logged in.  If he is, he got there because he bookmarked the login page, got the
'container' login page, logged in and was redirected to the 'application' page
(that happens to be the same).  In that case, redirect to the application
default page.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page





--- Additional Comments From [EMAIL PROTECTED]  2002-06-12 14:13 ---
That looks like a valid WORKAROUND but I believe this is something that I as a
developer shouldn't have to handle.  This should all be handled seemlessly by
the container.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-11 20:06 ---
Add this to the beginning of your login page:

<% 
  if (request.getHeader("Referer") == null) {
response.sendRedirect("index.jsp");
  }
%>

Replacing "index.jsp" with whatever URL you feel you want
to have your connection redirected to...

For example, if "index.jsp" is one of several "protected" resources,
then if your users bookmark the login page, what will happen is
that when your users use the bookmark, they won't have a referer,
not having a referer they will be redirected to what you think it is
their "default" page (after they have logged in), this (since they're not
logged in) will trigger a redirect again to the login page...

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page





--- Additional Comments From [EMAIL PROTECTED]  2002-06-11 19:40 ---
I still think this is a bug.  If it is not allowable for the user to bookmark
the login page then the container should never expose that login url to the
user.  In other words, Tomcat should not issue a browser redirect to the login
url but instead should do the equivalent of a jsp forward and after
authentication do a redirect back to the original url.  Thus there is no
possibility for the user to bookmark the page and get an ugly 400 error.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Bojan Smojver]

Bojan Smojver wrote:
> 
> I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
> based authentication:

Just to clarify here, 'my own' means in my own app, not something I've
coded separately from TC.

Bojan

Re: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Bojan Smojver]

I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
based authentication:

Pages:

/login/login.vm <-- login page
/login/error.vm <-- error page
/login/index.vm <-- default index page

If someone goes to /login/login.vm directly and gets authenticated, the
page /login/index.vm gets displayed, which can then do whatever it wants
(ie. redirect somewhere else, display error, content etc.)

The pages I use are Velocity pages, but I don't think that JSP would be
any different.

Bojan

Steve Downey wrote:
> 
> "Train the user not to do that" is a cop out. If an application doesn't work
> the way users expect, it's a problem with the application, not the user.
> That's usability 101.
> 
> If the user shouldn't bookmark the login page, they shouldn't ever be
> exposed to the URI for the login page. That makes it impossible to bookmark.
> The only URI that the user should see is the URI for the protected resource.

RE: DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[Steve Downey]

"Train the user not to do that" is a cop out. If an application doesn't work
the way users expect, it's a problem with the application, not the user.
That's usability 101. 

If the user shouldn't bookmark the login page, they shouldn't ever be
exposed to the URI for the login page. That makes it impossible to bookmark.
The only URI that the user should see is the URI for the protected resource.



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 03, 2001 6:23 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839
> 
> Problem bookmarking login page
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> --
> --
>  Status|REOPENED|RESOLVED
>  Resolution||WONTFIX
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED]  
> 2001-10-03 15:23 ---
> The fact that you hd the same problems under WebLogic also 
> should have given you
> a hint that you might be mis-using this functionality :-).
> 
> Although the form login page (and form error page) are 
> physically contained in
> your web application archive, they should not be hyperlinked 
> to by any of your
> app's pages.  Most particularly, it should *not* be your welcome page.
> 
> If you (temporarily) switch your app to use BASIC 
> authentication instead, it
> should still work correctly - and there is no possibility to 
> bookmark the login
> page because there is no such thing.  If your app doesn't 
> work in this scenario,
> then you should modify it so that it can.
> 
> If you don't, then you're going to be dependent on 
> non-portable behavior of
> whatever container vendor happens to allow this technique to 
> work - the spec 
> doesn't require it.
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 15:23 ---
The fact that you hd the same problems under WebLogic also should have given you
a hint that you might be mis-using this functionality :-).

Although the form login page (and form error page) are physically contained in
your web application archive, they should not be hyperlinked to by any of your
app's pages.  Most particularly, it should *not* be your welcome page.

If you (temporarily) switch your app to use BASIC authentication instead, it
should still work correctly - and there is no possibility to bookmark the login
page because there is no such thing.  If your app doesn't work in this scenario,
then you should modify it so that it can.

If you don't, then you're going to be dependent on non-portable behavior of
whatever container vendor happens to allow this technique to work - the spec 
doesn't require it.

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 14:11 ---
ohh, come on, you are saying "the solution is to fix the people who use your web 
application". What am I supposed to do, put in the login page something like this:"Do 
not bookmark this page, consider it a part of the *container*, not part of the 
*application*" Some of the users don't even know there is such thing as a container, 
and I don't see a reason why they should know.I don't see why the users should be 
instructed at all.Well, that really does not make it transparent for the users. I used 
to use weblogic and they had the same problem. They did change it to go to the default 
page in the web application after we contacted support.Plus the page IS part of the 
application, it has to be placed inside the war file, it is different for every web 
application, it has to be specified inside web.xml which is part of the standard. 
Exactly what part of the servlet standard is broken by fixing this?What good is the 
default page for the web application if it doesn't get shown by default?

DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2001-10-03 11:15 ---
It is not valid to bookmark the form-based login page.  You should consider that
page to be part of the *container*, not part of the *application*.

Users should be trained to bookmark the page they really want to see -- exactly
as if you were using BASIC authentication instead.  The login page will be
presented by the container if necessary (i.e. if the user is not currently
authenticated).

Even if you figure out a way to do this that works in one servlet container, it
is pretty much guaranteed not to be portable to any other.