Sure, one is that i want custom login screens, another is that we store
all our authentication details centrally and query for them via an XML
data service.
Various user and domain-specific data, including user preferences,roles
etc. is stored in this repository, not just 'yes, this user has blanket
access to the site'.
Our permissions-management tools are all written to work with this, so i
have an existing system i must fit my tomcat-based solutions into here.
I do use tomcat's basic authentication facilities for some unrelated
services, but for us it makes a lot of sense to centralize
authentication and preference data this way.
If someone writes an app that doesn't protect the page? well, then the
page is unprotected.
Security never comes completely for 'free', and in my experience it is
beneficial to place some onus on the developer to at least think about
security during the course of development.
YMMV, of course, but this approach has worked well for us.
-Pete
> Pete,
>
>
> Interesting that you don't use the container's authentication mechanism
> to protect pages. What if someone writes an app that doesn't protect
> the page. Any reason why you chose this route?
>
> Rgds
> Antony
