Amy

Yes - much too strict for JNDIRealm! The only configuration attributes 
that should always be specified for this realm are className and 
connectionURL. In addition either userPattern or userSearch must be 
specified (but not both). Other attributes either have default values, 
or not specifying them is itself significant (e.g. if userPassword is 
not specified the realm attempts to bind as the user rather than 
retrieve the user's password). (Note that the realm docs on the website 
are out of date, but the CVS and 4.1.8+  releases have new documentation 
which covers all of this).

In this connection, there is a problem with the admin application, which 
when it writes out a new version of the server.xml file converts all 
attributes that are unspecified by the user (e.g. in the original 
server.xml file) to attributes that are specified and have the empty 
string as their value This breaks JNDIRealm at the moment, and perhaps 
some other components as well (e.g. other realms).

However  I suspect this might be awkward to fix because of the way web 
forms work. If you can confirm that the admin app will continue to 
behave in this way (replacing null values with "" for all configuration 
attributes) then I can send you a patch for JNDIRealm to treat these 
values as equivalent. Configuration code in other components might also 
need to change - e.g. RealmBase decides whether a digest is being used 
by testing the value of the digest attribute against null, and throws an 
exception if it gets the empty string, since this is not null but not 
the name of a known digest algorithm either.

John


Amy Roh wrote:

> JDBC and JNDI Realms have many attributes.  What's the minimum list of 
> attributes to enable these two Realms?  I'll need to know the minimum 
> required list of attributes to validate the realm pages in admin 
> webapp.  Currently, it's validating all the fields as required which I 
> think is too strict.
>
> Thanks,
> Amy
>
>
> -- 
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to