Is it customary for a Sling Auth Handler's extractCredentials(..) method to be responsible for
1) validating human-supplied credentials (username, password) 2) and issuing a authentication token (ex. a secure auth Cookie) My understanding was a Auth Handler merely authenticates credentials, and generally doesnt actively issue tokens. An example flow might be: 1) User POSTs username/password to servlet. 2) Servlet authenticates credentials (via whatever means necessary, may need to reach out to 3rd party system) 3) Servlet adds a secure auth cookie to response object 4) Servlet redirects to resource /page/b.html 5) Authentication Handler matches on /page/b, extracts the secure auth cookie, validates, and "logs" the user in for that request This makes sense to me, but org.apache.sling.commons.auth.Authenticator.login(request, response) seems to imply they can/should be used to authenticate requests that come in as unauthenticated, and the servlet then issues an auth request. I believe a sample flow would be: 1) User POSTs username/password to servlet. 2) Servlet authenticates credentials (via whatever means necessary, may need to reach out to 3rd party system) 3) Servlet adds a secure auth cookie to response object *4) Servlet calls Authenticator.login(..)* *5) Servlet then can perform actions as the new user (not-anonymous anymore) *4) Servlet redirects to resource /page/b.html 5) Authentication Handler matches on /page/b, extracts the secure auth cookie, validates, and "logs" the user in for that request Should a Sling Auth Handler ever be used to handle Steps 2 and 3, effectively having two Sling Auth Handlers: One to authenticate the human supplied username/password and to issue a secure auth cookie, and Another to authenticate the secure auth cookie on subsequent requests?
