securityfilter architecture questions

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1563658118==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigDBBD46CBD03518E8FE60B9DF"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDBBD46CBD03518E8FE60B9DF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Max,

One of the issues in the buglist is to make securityfilter "more
extensible". Since you can replace the Authenticator and Realms at will,
I was looking into the code to see if there's anything we can reasonable
do to SecurityFilter.java to make it more tinker-friendly.

This has raised a couple of questions in my mind:

1. Why does the try/catch block around the call to
   matchPattern() include the calls to authenticator.processLogout
   and authenticator.processLogin? Was that simply an oversight, or
   is there a reason to include that code in the try/catch block.

2. Why does the above catch block catch all Exceptions, instead of
   just those related to pattern matching (as indicated by the error
   message that is produced).

3. Why do we call request.getSession(true) immediately after calling
   request.getSession().invalidate()? Why not let the session stay dead?

4. Is there a reason why Authenticator.processLogin is a single method
   that both determines if there is login information /and/ actually
   performs the login? Does it seem reasonable to split that up into
   to methods: isLoginRequest and doLogin (or something similar)?

   Same question with processLogout.

5. Is it appropriate for the Authenticator implementations to call
   methods on the Realm? It seems to me that the filter itself might be
   a better place for that. So, instead of this:

   filter:   authenticator.processLogin()
   -> auth:     realm.authenticate()

   We could do:
   filter: authenticator.getCredentials()
   filter: realm.authenticate(credentials)

   This would be nice because then things like supporting
   FlexibleRealmInterface would all be contained within the filter
   instead of spread over the authenticator implementations.

   Perhaps what we really need to do is re-name the authenticators.
   The FormAuthenticator is really the FormCredentialSolicitor or
   something like that.

   Right now, BasicAuthenticator does not support
   FlexibleRealmInterface, and neither does PersistentLoginManager
   (available only through the FormAuthenticator, which is a shame).

   If we re-thought the way that the existing Authenticators are
   designed (or maybe just named), I think the code would become more
   elegant.

   If we were to do this, many orthogonal features to authentication
   (such as "remember me" functionality) could be moved out of the
   authenticators and back into the filter where they could be used
   by all of the authenticators.

   It's not entirely sill to support remember-me with BASIC auth...
   It's still possible to set cookies and receive them even when the
   credential gathering scheme is to use BASIC Auth.


That's about it for now. I can see some obvious changes that I'd like to
make that do not change the architecture at all -- they just make the
code a bit more readable, etc.

Let me know what you think.

Thanks,
-chris


--------------enigDBBD46CBD03518E8FE60B9DF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHK51K9CaO5/Lv0PARAi+DAJ4gcz8WEwQibDZqqjvPxPengr4REgCggBEk
Yb6zDY7M3YJPlhMSP3YG8rg=
=LEhp
-----END PGP SIGNATURE-----

--------------enigDBBD46CBD03518E8FE60B9DF--


--===============1563658118==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--===============1563658118==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
securityfilter-devel mailing list
securityfilter-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/securityfilter-devel

--===============1563658118==--