[
http://jira.dspace.org/jira/browse/DS-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11669#action_11669
]
Tim Donohue commented on DS-616:
--------------------------------
This issue was discussed in the Developer Meeting on 08 Sept 2010.
It was determined that this issue needs further study. We understand the
problem here, and hope that as DSpace moves towards using the newer
ConfigurationService (which is only used by a few areas of DSpace right now) we
can get around this issue. Essentially, a proper fix may require a lot of API
level changes -- but we need to investigate this to be certain.
[20:28] <tdonohue> DS-616: Make it possible to guarantee config file values are
filled thru the ConfigurationManager API
http://jira.dspace.org/jira/browse/DS-616
[20:30] <tdonohue> ?? I thought most of our code tends to check for configs and
report if they are missing (rather than throwing NullPointers?). Beyond that,
I'm not sure what else is implied?
[20:30] <mhwood> Maybe this should be part of moving toward
ConfigurationService?
[20:31] <grahamtriggs> I don't like the proposed solution - if anything it
should be a separately named method, not a boolean parameter (which in itself
would be confusing with the operation of getBooleanProperty)
[20:32] <tdonohue> Yea, I guess the ConfigurationService could help this
perhaps -- though in general we should be checking for existance of configs
when they are needed
[20:32] <grahamtriggs> but if you are going after the places in the code to
force them to call the configuration manager in a certain way, then you can go
after them to simply check the return values properly and log meaningful
(instead of generic) messages
[20:33] <mdiggory> ConfigurationService accepts default values for parameters
when looking them up.
[20:33] <richardrodgers> also wouldn't this require all callers of
ConfigManager to rewrite code (a big deal)?
[20:33] <mdiggory> ConfigurationService should replace COnfigurationManager
wherever possible
[20:34] <mdiggory> but I'm not so keen on the ticket, its upto the calling code
to deal with the failure to retrieve a value appropriately
[20:34] <mdiggory> and to supply sane defaults in the code, not the
configuration file
[20:35] <grahamtriggs> mdiggory: it's not just default values - sometimes there
isn't a sensible default, you must have something configured. But the answer is
to make the calling code work correctly, not fudge it inside the API
[20:35] <tdonohue> I agree -- I'd vote -1 on this issue, but I think we find
places where the code is not catching the potential NullPointer, and fix it
there
[20:35] <richardrodgers> so annotate ticket 'for further study'
[20:35] <mdiggory> in fact... dependening on implementation, the source of the
configuration value is abstracted away from the file itself
[20:36] <mdiggory> could be database... could be some other source...
[20:36] <mdiggory> agree... further study
[20:36] <tdonohue> yea, we probably should just mark this "for further study"
and keep it in mind as we move towards ConfigurationService
[20:36] <mhwood> Yes, needs more thought.
[20:36] <tdonohue> ok, DS-616 -- needs more study -- keep in mind for
ConfigurationService
> Make it possible to guarantee config file values are filled thru the
> ConfigurationManager API
> ---------------------------------------------------------------------------------------------
>
> Key: DS-616
> URL: http://jira.dspace.org/jira/browse/DS-616
> Project: DSpace 1.x
> Issue Type: Improvement
> Reporter: Flávio Botelho
> Original Estimate: 10 minutes
> Remaining Estimate: 10 minutes
>
> Sometimes users leave certain necessary config values commented and instead
> of getting nice error messages back telling that a certain value needs to be
> filled, a random exception (most of the time it will probably be NullPointer)
> comes back.
> It is as easy as adding a boolean flag to getProperty in ConfigurationManager
> so that if the flag is true, it should make sure it wont return null, if the
> value is null it should log and error message and simply 404.
> The hard part would be go after the places in code that should call
> getProperty with the flag true, but i guess that can be done over time...
> Example of emails on dspace-tech showing that happening:
> Aha! I now realize what it is. The ldap.search_scope value is
> commented out by default in the config file. I mistakenly believed that
> this implied a default value of 2. If you leave the value commented out
> and enable Hierarchical LDAP authentication, you generate a
> NullPointerException.
> All appears to be well. Thanks everyone.
> Jason
> - Hide quoted text -
> On 6/25/10 4:24 PM, Stuart Lewis wrote:
> > Hi Jason,
> >
> > DSpace ships with two LDAP options - LDAPAuthentication and
> > LDAPHeirarchicalAuthentication.
> >
> > If all your users are in one branch of an ldap tree (e.g. they all exist in
> > ou=users,dc=unb,dc=ca) then you can use the former. This does not perform
> > an initial bind, it just binds to the user's DN using their credentials. If
> > the bind is successful then it allows the user to log in to DSpace.
> >
> > If your users are scattered across many different branches, then you'll
> > need to use the LDAPHeirarchicalAuthentication option. This has extra
> > settings in dspace.cfg to set the DN and password of a user who has search
> > rights across the LDAP directory. DSpace will bind as that user and then
> > perform a search to find the DN of the user who is trying to log in. Once
> > it finds that, it then binds a second time to that DN, using the user's
> > password.
> >
> > Hopefully the comments in dspace.cfg will guide you through the different
> > settings. This blog post has some examples settings in that might help
> > demonstrate what you need to put in where:
> >
> > -
> > http://blog.stuartlewis.com/2008/08/18/test-ldap-service-upgraded-now-with-branches/
> >
> > Thanks,
> >
> >
> > Stuart Lewis
> > IT Innovations Analyst and Developer
> > Te Tumu Herenga The University of Auckland Library
> > Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand
> > Ph: +64 (0)9 373 7599 x81928
> >
> >
> > On 26/06/2010, at 2:51 AM, Jason Nugent wrote:
> >
> >> Hi folks,
> >>
> >> Just to confirm, does DSpace perform a two step check and then bind for
> >> authentication? I ask, because I've been talking to the fellow who has
> >> access to our LDAP server logs and he has informed me that it appears as
> >> though DSpace is attempting to bind with uid=jnugent,dc=unb,dc=ca, which
> >> is obviously incorrect. What it *should* be doing is an initial search
> >> with (uid=jnugent) as a filter, using the
> >> ldap.search_user/search_password, and then retrieving the DN for my
> >> record and binding with that, and the supplied password. In my case, my
> >> full DN is unbCaId=XXXXXXX,ou=people,dc=unb,dc=ca where XXXXXX is a
> >> unique string. Our users would never know what that string was.
> >>
> >> It sounds as though the setting for ldap.object_context is involved in
> >> this, since it is appended to the ldap.id_field and username, but in my
> >> case, I'd want it appended to unbCaID=XXXXXX, not my uid=jnugent string.
> >>
> >> Regards,
> >>
> >> Jason
> >> --
> >> Jason Nugent
> >> Systems Programmer/Database Developer
> >> Electronic Text Centre
> >> University of New Brunswick
> >> [email protected]
> >> (506) 447 3177
> >>
> >> ------------------------------------------------------------------------------
> >> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> >> lucky parental unit. See the prize list and enter to win:
> >> http://p.sf.net/sfu/thinkgeek-promo
> >> _______________________________________________
> >> DSpace-tech mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> >
> >
> >
> >
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
