I'm glad to hear that you have things working. I have been following the discussion, and I'd like to understand where we might make the migration task easier. Since Servlet 3.0 is the first rev of the Servlet Spec to require and test compatibility of security constraint processing (among non-EE compatible Servlet containers) , it may be that some of the problems you have seen are the result of differences between the way Tomcat processes security constraints, and the way EE compatible containers process security constraints. In looking at your web.xml, it appears that you defined 3 role-based constraints.
The first is on /loggedIn.jsp (an exact pattern). In a Servlet 3.0 or in an EE compatible container it applies only to methods GET and POST and requires that the caller be logged in and in role member.
In your last post,
The second, is on /login.do (and exact pattern). In a Servlet 3.0 or in an EE compatible container, it applies only to method GET and requires that the caller be logged in and in role member.
The third, is on *.do (a lower priority extension pattern). In a Servlet 3.0 or in an EE compatible container, it applies only to method POST and requires that the caller be logged in, and in role member. It does not apply to requests that match /login.do
when a request is received that matches one of the above constraints, there will be an access check to determine if the caller has access. if not, and a caller Principal has not yet been established, the Form Login Authenticator will be invoked to cause a login (which will involve the JDBC realm) Otherwise a 403 will be returned.
since GET is only constrained at /loggedIn.jsp and /login.do; and POST is only constrained at /loggedIn.jsp and *.do; I would expect most requests to be accepted independent of authentication.
when a 403 is returned, it means the caller has been authenticated, but is not in a permitted role; which may mean that at the time your app was deployed, it did not define or employ a principal 2 role mapping that would map the user to the member role.
Lastly, I am not sure why you are being returned to the LoginPage.jsp. Given the web.xml you have provided, The Glassfish container should only redirect to the LoginPage.jsp, when an attempt is made by an unauthenticated caller (as seen by the container) to access a role-protected url using a protected HTTP method. In you last post, it appears that you may have attributed that problem to a redirect by your app to the value of the "referer" header.
FWIW, Glassfish v3 differs from Tomcat in the way its FormAuthenticator transitions to the login page. Glassfish does a redirect (under some circumstances) while Tomcat does a forward. Glassfish made this change to ensure proper enforcement of user-data-constraints on the login page. Perhaps this difference has some role in the difference in bahavior you are seeing wrt to the "referrer" header. In any event, we are further revising V3.1 such that the constraints will be processed, but the transition will be by forward.
[Message sent by forum member 'monzillo' (ronald.monzillo_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=381839