> 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
