RE: FORM-based authentication idea
-Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 11:55 AM To: [EMAIL PROTECTED] Subject: Re: FORM-based authentication idea The best way to think about form-based login is like this: * The login page is (in essence) part of the container, not the application. Therefore, ... * The login page should *never* be referenced directly by any other application page, and ... * The login page should *never* be requested directly by the user. How do you enforce that a particular URL should never be asked for by a user? Installing it under WEB-INF is one way. The container will then enforce the prohibition. However, in general, not publishing the URL anywhere is probably sufficient. It's not as though with form based login that the user ever has to see the URL of the login form. -SMD 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.
Re: FORM-based authentication idea
The best way to think about form-based login is like this: * The login page is (in essence) part of the container, not the application. Therefore, ... * The login page should *never* be referenced directly by any other application page, and ... * The login page should *never* be requested directly by the user. How do you enforce that a particular URL should never be asked for by a user? Shouldn't the responsibility to handle that case rest with the JSP container and not the user? Isn't that kind of like designing a user interface where a button shouldn't be clicked when the program is in a certain state and instead of making the button invisible or disabled when in that state, you simply say well, the user shouldn't click that button when the program is in that state Using form-based login pages in any other manner is just going to cause you grief, unless and until the servlet spec were changed to mandate a behavior like what you propose. NOTE: A primary reason that form-based login was designed the way it is was to emulate the user experience of how BASIC login works. With BASIC, you never reference the login page directly, right? It just pops up whenever you try to access a protected resource for the first time -- then, you are transparently returned to the resource you originally requested. Using form-based login lets you manage the look-and-feel of the login page, but it should *not* be part of your application's normal flow. Any thoughts? -Mike Craig McClanahan
Re: FORM-based authentication idea
Why is the button there at all? There should be zero linkages to the login page from *anywhere* in your user interface. That's true. The point I was trying to make is that there is nothing to stop an end-user from bookmarking a login page or typing it in directly, even if you have no linkages to the login page in your user interface. NOTE: If you don't like the philosophy of form-based login, the appropriate forum is the feedback address for the servlet spec ([EMAIL PROTECTED]), because that is where the requirements for how Tomcat works are defined. Craig Thanks! I'll forward my suggestion on to them. -Mike
Re: FORM-based authentication idea
On Thu, 21 Jun 2001, Michael Jennings wrote: That's true. The point I was trying to make is that there is nothing to stop an end-user from bookmarking a login page or typing it in directly, even if you have no linkages to the login page in your user interface. It's kinda hard for them to bookmark the login page when they don't know the URL. Keep in mind that, as far as the browser is concerned, the URL in the location is still the page that was originally requested. Therefore, a bookmark for the login form will actually be to the real page (which might again trigger authentication if they have exited and restarted before following the bookmark). Not quite true. In most cases the login page will not be in the same directory with the page that needs authentication. If the container does not send a redirect, but internally displays the login page, all the relative URLs will be treated by the browser as relatvie to the authenticated page, not the login page. Since the spec doesn't mention that the login pages are not allowed to have relative URLs - I'm not sure it's that easy to implement the form login without a redirection. And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the container is supposed to redirect to the originally requested page after authentication is completed. The net effect of this is that the URL of the login page is never visible to the user, unless you have deliberately linked to it in your user interface. That's one of the reasons such links should not exist. Costin
Re: FORM-based authentication idea
It's kinda hard for them to bookmark the login page when they don't know the URL. Keep in mind that, as far as the browser is concerned, the URL in the location is still the page that was originally requested. Therefore, a bookmark for the login form will actually be to the real page (which might again trigger authentication if they have exited and restarted before following the bookmark). Right now I've got a web app set up with tomcat 3.2.2 using form-based authentication, when I request /WWAT2/user/welcome.jsp I get redirected to /WWAT2/login.jsp which I see in my address bar. Just for fun I bookmarked it, logged in, then I was redirected to /WWAT2/user/welcome.jsp (which was my original request) I logged out, then went to my bookmarked /WWAT2/login.jsp So it looks like I do see the login URL. (I have absolutely no links to the /WWAT2/login.jsp anywhere) So what you are saying is that if a user doesn't see the login URL, there are no links to it in the web-app, the chances of them requesting JUST the login page of a web-app are so few and far between that handling that special case should just be ignored? Is there something wrong with my tomcat configuration? The form-based authentication works like a dream except for showing me the URL of the login page. The behaviour is fine. -Mike And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the container is supposed to redirect to the originally requested page after authentication is completed. The net effect of this is that the URL of the login page is never visible to the user, unless you have deliberately linked to it in your user interface. That's one of the reasons such links should not exist. NOTE: If you don't like the philosophy of form-based login, the appropriate forum is the feedback address for the servlet spec ([EMAIL PROTECTED]), because that is where the requirements for how Tomcat works are defined. Craig Thanks! I'll forward my suggestion on to them. -Mike Craig
Re: FORM-based authentication idea
Okay, I was being stupid. I understand now, with form-based authentication when you request /mywebapp/private/somefile.jsp what you get back should just be generated from the login page, then when you submit your credentials, it returns whatever is generated from /mywebapp/private/somefile.jsp So the redirection thing is just how it is implemented right now. Stupid me. -Mike - Original Message - From: Michael Jennings [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 2:21 PM Subject: Re: FORM-based authentication idea It's kinda hard for them to bookmark the login page when they don't know the URL. Keep in mind that, as far as the browser is concerned, the URL in the location is still the page that was originally requested. Therefore, a bookmark for the login form will actually be to the real page (which might again trigger authentication if they have exited and restarted before following the bookmark). Right now I've got a web app set up with tomcat 3.2.2 using form-based authentication, when I request /WWAT2/user/welcome.jsp I get redirected to /WWAT2/login.jsp which I see in my address bar. Just for fun I bookmarked it, logged in, then I was redirected to /WWAT2/user/welcome.jsp (which was my original request) I logged out, then went to my bookmarked /WWAT2/login.jsp So it looks like I do see the login URL. (I have absolutely no links to the /WWAT2/login.jsp anywhere) So what you are saying is that if a user doesn't see the login URL, there are no links to it in the web-app, the chances of them requesting JUST the login page of a web-app are so few and far between that handling that special case should just be ignored? Is there something wrong with my tomcat configuration? The form-based authentication works like a dream except for showing me the URL of the login page. The behaviour is fine. -Mike And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the container is supposed to redirect to the originally requested page after authentication is completed. The net effect of this is that the URL of the login page is never visible to the user, unless you have deliberately linked to it in your user interface. That's one of the reasons such links should not exist. NOTE: If you don't like the philosophy of form-based login, the appropriate forum is the feedback address for the servlet spec ([EMAIL PROTECTED]), because that is where the requirements for how Tomcat works are defined. Craig Thanks! I'll forward my suggestion on to them. -Mike Craig
Re: FORM-based authentication idea
On Thu, 21 Jun 2001, Michael Jennings wrote: Okay, I was being stupid. I understand now, with form-based authentication when you request /mywebapp/private/somefile.jsp what you get back should just be generated from the login page, then when you submit your credentials, it returns whatever is generated from /mywebapp/private/somefile.jsp That would be nice - if possible. I spent quite a bit of time finding workarounds that would allow such a behavior. If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. So the redirection thing is just how it is implemented right now. Stupid me. Probably it's me the one - since everyone seems to know how to implement such a thing except me. Costin
Re: FORM-based authentication idea
On Thu, 21 Jun 2001 [EMAIL PROTECTED] wrote: On Thu, 21 Jun 2001, Michael Jennings wrote: Okay, I was being stupid. I understand now, with form-based authentication when you request /mywebapp/private/somefile.jsp what you get back should just be generated from the login page, then when you submit your credentials, it returns whatever is generated from /mywebapp/private/somefile.jsp That would be nice - if possible. I spent quite a bit of time finding workarounds that would allow such a behavior. If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. The form login page should use server-relative URLs, or a base tag in the head section. That way, the initial display of the login page will work correctly even on a container that does (what amounts to) a RequestDispatcher.forward() to the login page. So the redirection thing is just how it is implemented right now. Stupid me. Probably it's me the one - since everyone seems to know how to implement such a thing except me. Costin Craig
Re: FORM-based authentication idea
On Thu, 21 Jun 2001, Craig R. McClanahan wrote: If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. The form login page should use server-relative URLs, or a base tag in the head section. That way, the initial display of the login page will work correctly even on a container that does (what amounts to) a RequestDispatcher.forward() to the login page. Should != must. AFAIK there is no restriction on what is allowed in a login page - except the use of special name for the action and variables. That mean a page using relative URLs is legal, and the container must deal with it. ( I don't know too many pages using the base tag anyway, and relative URLs are prefered in many cases - I would say they are far more frequent than server-relative URLs ). Costin
Re: FORM-based authentication idea
FWIW, I ran into this problem with users bookmarking the login page and returning to it without trying to access a protected resource. In the current implementation in 3.2.2, I don't think you can prevent that, can you? After being authenticated, the user was being dropped into the directory that contained my login.jsp. I found the easiest solution was to have my login.jsp in it's own directory with an index.jsp that simply redirects to the appropriate page inside my protected resource. Took me about a minute to implement and it works well. Craig, from your previous posts I am under the impression that the current implementation for form-based logins uses a sendRedirect() -- which is why you can see and bookmark the URL for your login.jsp page (3.2.2). Is this correct? Is that going to change to use RequestDispatcher.forward() in the future? If so, that should solve the bookmarking problem. Thanks, --jeff P.S. -- I always use server-relative links, but I'm a programmer! :o) My designers using Dreamweaver always send me files with relative links... - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 4:48 PM Subject: Re: FORM-based authentication idea On Thu, 21 Jun 2001, Craig R. McClanahan wrote: If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. The form login page should use server-relative URLs, or a base tag in the head section. That way, the initial display of the login page will work correctly even on a container that does (what amounts to) a RequestDispatcher.forward() to the login page. Should != must. AFAIK there is no restriction on what is allowed in a login page - except the use of special name for the action and variables. That mean a page using relative URLs is legal, and the container must deal with it. ( I don't know too many pages using the base tag anyway, and relative URLs are prefered in many cases - I would say they are far more frequent than server-relative URLs ). Costin
Re: FORM-based authentication idea
Andy Armstrong wrote: Michael Jennings wrote: Hi everyone, I just wanted to bounce an idea off of everyone. In tomcat, when one specifies form-based authentication you have to tell tomcat which page is the login page. This is done via the context's web.xml file by setting the form-login-page property under the login-config section. When a user hits a protected URL in a context, if they are not already authenticated, the original request page is saved in their session, then they are redirected to the login page, if the login succeeds, they are redirected to their original request page. A problem happens however, when a user requests JUST the login page. After logging in, there is nowhere to redirect the user to since their is no original request saved in the session. What if there was a concept of a default login target? so that when a user requests just the designated login page, if they are already authenticated, they get redirected to the default login target page. Similarly, if a user requests the login page but they are not authenticated, upon logging in they would get redirected to the default login target. I realize that this is probably not in the JSP spec, but something like this seems to be necessary. The alternative is to look for the presence of a session variable called tomcat.auth.originalLocation and set up a default from within the login page if that session variable isn't there. Any thoughts? Why not supply the default in a hidden field on the login page? -- Andy Armstrong, Tagish FWIW, I guess I could see some small convenience in a target-fail and target-succeed context parameter. I guess I if I had multiple entry points into my application, such as a more complex manual authentication routine within a different application or something, I could also grab these values for all successful or failed attempts to access the system. I guess it would let me standardize my authentication result pages and have them listed in one single place, which means I would probably name them auth-fail-target and auth-succeed-target rather than making them login-specific. Then again, I could probably implement this same thing in a dozen other ways or using my own custom context param tags. I guess my personal feeling is that it probably wouldn't be an obtrusive feature, and many users may in fact find it convenient. My main objection would be that it is adding non-spec features, which means that any apps written under Tomcat would not cleanly port to other spec-compliant servlet containers. Just my $.02. - Christopher
Re: FORM-based authentication idea
Christopher Cain wrote: My main objection would be that it is adding non-spec features, which means that any apps written under Tomcat would not cleanly port to other spec-compliant servlet containers. This, of course, should read: Any apps written under Tomcat to levarage this feature would not port cleanly. Basically, it encourages developers to code outside of the spec. If they relied on their own custom tags to do the job, then they just transplant their custom web.xml.
Re: FORM-based authentication idea
FWIW, I guess I could see some small convenience in a target-fail and target-succeed context parameter. I guess I if I had multiple entry points into my application, such as a more complex manual authentication routine within a different application or something, I could also grab these values for all successful or failed attempts to access the system. I guess it would let me standardize my authentication result pages and have them listed in one single place, which means I would probably name them auth-fail-target and auth-succeed-target rather than making them login-specific. Then again, I could probably implement this same thing in a dozen other ways or using my own custom context param tags. I guess my personal feeling is that it probably wouldn't be an obtrusive feature, and many users may in fact find it convenient. My main objection would be that it is adding non-spec features, which means that any apps written under Tomcat would not cleanly port to other spec-compliant servlet containers. If someone uses a spec-compliant servlet container to set up a context called /abc/ with the form-login-page set to /abc/login.jsp and the form-error-page set to /abc/loginerror.jsp and all pages in /abc/admin/* needing a user with administrator role for access and all pages in /abc/webuser/* needing a user with the webuser role for access. What happens when an un-authenticated user simply requests /abc/login.jsp ? I suspect that what happens depends on your JSP container, since the spec doesn't seem to handle this case. If this proposed feature (default login target) was added to tomcat, then any JSP pages developed would just behave a bit nicer in this special case, they would still continue to work correctly in any spec-compliant jsp container. That's my $.02 anyhow. -Mike Just my $.02. - Christopher
Re: FORM-based authentication idea
On Wed, 20 Jun 2001, Michael Jennings wrote: Hi everyone, I just wanted to bounce an idea off of everyone. In tomcat, when one specifies form-based authentication you have to tell tomcat which page is the login page. This is done via the context's web.xml file by setting the form-login-page property under the login-config section. When a user hits a protected URL in a context, if they are not already authenticated, the original request page is saved in their session, then they are redirected to the login page, if the login succeeds, they are redirected to their original request page. A problem happens however, when a user requests JUST the login page. After logging in, there is nowhere to redirect the user to since their is no original request saved in the session. What if there was a concept of a default login target? so that when a user requests just the designated login page, if they are already authenticated, they get redirected to the default login target page. Similarly, if a user requests the login page but they are not authenticated, upon logging in they would get redirected to the default login target. I realize that this is probably not in the JSP spec, but something like this seems to be necessary. The alternative is to look for the presence of a session variable called tomcat.auth.originalLocation and set up a default from within the login page if that session variable isn't there. The best way to think about form-based login is like this: * The login page is (in essence) part of the container, not the application. Therefore, ... * The login page should *never* be referenced directly by any other application page, and ... * The login page should *never* be requested directly by the user. Using form-based login pages in any other manner is just going to cause you grief, unless and until the servlet spec were changed to mandate a behavior like what you propose. NOTE: A primary reason that form-based login was designed the way it is was to emulate the user experience of how BASIC login works. With BASIC, you never reference the login page directly, right? It just pops up whenever you try to access a protected resource for the first time -- then, you are transparently returned to the resource you originally requested. Using form-based login lets you manage the look-and-feel of the login page, but it should *not* be part of your application's normal flow. Any thoughts? -Mike Craig McClanahan
