Page History

...

1.  Brief discussion about Amherst College's acrepo apache camel services: https://gitlab.amherst.edu/acdc/repository-extension-services
   1. perhaps more conversation about what these are at a later meeting. 
2. Accessing Modeshape layer WebACFilter:  issue
   1. adding Acl:append checking - there are some differencdifference in how Acl:append works in POST: for example you can post to a RDF source but not a non-RDF source.   In looking up the nodes in modeshape, via spring configuration, things are not actually getting injected into the webac filter.  Peter may have been using the wrong configuration file to do this with. 
   2. webac code is in the WebACFilter - but perhaps some of the checks belong in the FedoraLdp class, so that access to node data is readily available.  Concern with doing that is that authorization would be split between to two places and do we want authorization that close to the HTTP API core? 
   3. webac is like a shield around the HTTP interface.  Maybe a way to make a call that's unfiltered?  We need to be able to distinguish requests that need to be filtered and ones that do not (internal requests), to ensure they are not going through the authorization chain again.   One solution could be internal admin credentials?
   4. Current approach is to pull in modeshape (fedora repo impl) to resolve question of what type of RDF resource it is.   That resource is not currently being injected into the webac.  Possible not configuring the correct spring file. 
   5. What about cases where authorization is not just happening out front - ie. cases like recursive delete.   That's an area where authorization checks might need to happen outside/after of the WebACFilter.
      1. Jira ticket for looking at WebAC and recursive deletes where authorization might be different for child nodes. 
      2. one possibility is that a recursive delete will delete what user is authorized to delete – or reject the request outright. 
   6. Andrew pointed out that moving the WebACFilter stuff into the HTTP layer is more out of necessity rather than architectural design – 
      1. more sound/maintainable approach by having the filter do it all, but barrier is getting the injection of fedora objects to work correctly
      2. generating more HTTP traffic when we're already inside the server isn't ideal
   7. Jared brought up the wizardOfOz approach (hidden user) - an internally credentialed (hidden) user whose requests are always just accepted by server. Perhaps tie it to the servers IP, so they are only locally generated requests. 
   8. Short term plan - move some WebACFilter stuff closer to the HTTP layer.  Danny will look at this some.  Fresh eyes on this welcome. 
3.  Fedora 5.0.0 Preparation Tasks
   1. CTS – all the tests are stubbed out now.  
   2. Documentation changes have slowed down.  Still work to do there. 
   3. Outstanding PR's awaiting review from folks - just one current one: https://github.com/fcrepo4/fcrepo4/pull/1386
      1. some JIRA tickets just need to be closed (the PR's were merged already)
4. September Sprint Planning 

...