Grouper Users - Open Discussion List

[graham <>]

GW Brown, Information Systems and Computing wrote:
> Hi Graham,
>
> I think the password problem occurs because of the way loadAttributes 
> works in JNDISourceAdapter:
>
> Set values = new HashSet();
>                for (NamingEnumeration en = attr.getAll(); en.hasMore(); ) {
>                    String value = (String) en.next();
>                    values.add(value);
>                }
>
> You could try:
>
>  Object value = en.next();
>  values.add(value.toString());

I've tried that with no joy. I believe the problem is coming from deeper 
than that; grouper_ui.log now shows:

2008-05-21 15:09:50,778 ERROR actions.GrouperCapableAction: < 
GrouperSystem 8EE00CF9611428E6F16E8E6AD76F3AA1-0008 
9b243998-d62a-4e7c-9e43-6bd37159fccb GrouperSystem g:isa > 
java.lang.ClassCastException: [B
        at 
edu.internet2.middleware.subject.provider.JNDISourceAdapter.loadAttributes(Unknown 
Source)
        at 
edu.internet2.middleware.subject.provider.JNDISubject.getAttributes(Unknown 
Source)
        at 
edu.internet2.middleware.grouper.ui.actions.PopulateSubjectSummaryAction.grouperExecute(PopulateSubjectSummaryAction.java:362)
        at 
edu.internet2.middleware.grouper.ui.actions.GrouperCapableAction$1.callback(GrouperCapableAction.java:206)
        at 
edu.internet2.middleware.grouper.internal.dao.hib3.Hib3TransactionDAO$1.callback(Hib3TransactionDAO.java:46)


and I think the issue is actually with getAttributes() trying to 
retrieve an inappropriate value from a Map:  the javadoc for Map says 
(unhelpfully):

"Attempting to insert an ineligible key or value throws an unchecked 
exception, typically NullPointerException or ClassCastException. 
Attempting to query the presence of an ineligible key or value may throw 
an exception, or it may simply return false; some implementations will 
exhibit the former behavior and some will exhibit the latter."

If that's what's generating my ClassCastException I need to block the 
ineligible value from getting into the Map in the first place, rather 
than tracking down the places where the value is extracted.

But if that's so I can't see why no-one else would have run into this 
problem before - surely everyone has passwords in their LDAP 
directories? I'm inserting mine into Fedora-DS in an ldif file like so:

userPassword: {SHA}Va8gQV6tDd1Bfzf6kaTHZ7dK7jQ=

Other applications seem happy to accept this format (ldapsearch simply 
does not display the password field, JXPlorer displays the password 
field name with '(non string data)' in the value field. Shibboleth works 
using the password).

Graham