Rm meeting february 3, 2012

Agenda

1. Security: I propose a potential change in the way we do Islandora security and would like to get some feedback: I would like to have Fedora live behind a firewall, so that we don't have to handle security at the Fedora level. The biggest thing that this allows us is that we can move away from the Fedora security model, where every object has a policy, to a model where we can inherit security from say parent collections. This would assume that only authorized applications have access to Fedora, it is not open to the public.
2. Final Decision on Supported OSes: Ubuntu LTS and CentOS 5.7. Any objections?
3. Update on Solr Views from Donald and Kirsta

• Further discussion on how we should use Views.

5. Progress update
6. Timing of next meeting

Meeting Minutes

This meeting got a bit off track because of the lack of attendees.

• Discussed security. Didn't discuss Jonathans idea of Fedora behind a firewall, because everyone at the meeting had already talked about it. Discussed Ben's idea of using objects in Fedora to manage security. Each user created in Drupal would have an object in Fedora. Could possible hook the user creation system in Drupal. Ben tasked with looking at this.

Hi Ben, Sorry I had to leave our meeting early today. I've been thinking a little about security and what you mentioned regarding the fedora objects. I think it's an interesting concept and may also work with what we are calling our Authority module (which is really a bunch of objects in Fedora that represent authors or institutions, then when filling out forms this list could help populate dropdowns etc.). Since we need to represent people in the repo anyway it may make sense to use the same or similar objects for authentication and authorization. We would still need a servlet filter of some kind to query the Fedora objects and a way to sync the drupal users with the fedora objects etc. Some of it we could do with hooks something like this:

<?php
/**
 * drupal hook_user
 * @param string $op
 * @param object $edit
 * @param object $account
 * @param <type> $category
 */
function sidora_islandora_user($op, &$edit, &$account, $category = NULL) {
 //@TODO add form elements for further info so we can populate more of the eac-cpf record (op == 'register' or op == 'edit')
 //@TODO will aslo have to update the eac-cpf on user update (op== 'update').
 module_load_include('inc', 'sidora_islandora', 'si_util');
 if ($op == 'insert') {
   $pid = sidora_islandora_create_user_object($edit);
 }
 if ($op == 'view') {
   $arr = unserialize($account->data);
   $pid = $arr['islandora_user_pid'];
   $account->content['islandora_user_pid'] = array(
     '#title' => t(' '),
     '#value' => l(t('My Projects'), 'fedora/repository/' . $pid),
     '#class' => 'islandora_user_pid',
     '#type' => 'user_profile_item');
 }
}

The function sidora_islandora_create_user_object($edit) would become a function in our user api etc. This user api could be called by other frontends if required.

I do see some potential pitfalls as well but it might be the right way to move our security forward. Can you spend sometime on this to see if you think it is feasible and document or code what we would have to store in Fedora etc.?

• Discussed dependency injection. This is very useful for testing. There was a suggestion of using a dependency injection framework, however we decided that we do not need to be that complicated. There was a suggestion of using a PHP class loader, however we decided that we should be using the Drupal class loader.

• Testing framework created in PHPUnit for the repository api code. This extensively uses dependency injection. This code will be used to create the API using test driven development. We need extensive testing of this API because it underlies the whole Islandora piece so it needs to be bulletproof.

Attendees

Jonathan, Paul, Ben