OK, for future expansion I'll keep the class and the
AuthenticationMethod.CMA setting for others' use, but I won't be
implementing it within the JSPs (you can though), i.e., password fields
that need to appear or disappear based on the usage of CMA, that will be
a function of how the users plan to implement it, and they can leverage
what we have for the other three auth methods to figure out what to do.
Glen
On 08/11/2014 09:37 AM, Dave wrote:
-1 I don't see the harm in leaving a partial implementation in place, it's
only one class and comments its presence might be the spark that causes
somebody to fix it it.
- Dave
On Mon, Aug 11, 2014 at 8:23 AM, Glen Mazza <[email protected]> wrote:
Hi Team, I'm presently going through the user profile/create user/modify
user JSPs to make sure they are working correctly (e.g., fields
hidden/shown) for our three working auth methods, DB, LDAP, and OpenID.
We also have a nonfunctioning CMA auth mechanism, it consists of one class
(RoleAssignmentFilter) and a three or four old references within the
application and no web.xml or other configuration necessary to get it to
work. I'd like to pull out that option for 5.1, until we get some user
demand for it, including a patch implementing it. Users have the 5.0.4
source code for ideas on how to implement CMA, at least on older Tomcats,
but they'll need to do some research on how to hook it up to their
particular servlet container. WDYT?
Regards,
Glen
