Page History

...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Minutes

1. API spec alignment sprint updates/questions
   1. Disabling versioning:
      • spec specifies how to turn on versioning, but not clear how to disable versioning
      • one approach is to DELETE timemap (LDPCv)
        • deletes all Mementos; could be overkill if you want to retain prior versions
      • use cases?
        • migration from versioned to unversioned repo
        • more important for server-managed versioning
        • less important for client-controlled versioning like we are doing it now
      • suggestions
        • disable write to the LDPCv via ACLs
        • original resource should still be marked as versionable using the link header, just that new versions cannot be created
        • versionable = has timemap
      • auto-versioning:
        • should the server act as a proxy for the user?
        • or should it always create versions?
        • create a user to represent the server?
          
          • is the server always a superuser? (as in the current implementation)
          • not yet specified in the spec
      • how does a client tell if a resource is presently versionable?
        • not possible without trying to create a version
      • if versions are server-managed, then the time-map is read-only?
        • or writes are restricted to the server user
      • creating a server user is the most transparent option for the ACL approach
   2. WebAC enabled by default
      • WAR file: yes
      • mvn jetty:run: yes
      • one-click JAR: NO (to retain its one-clickablity)
      • there is interest in having a switch to disable WebAC at deploy-time for WAR file
        • web.xml defining AuthN policy makes this tricky
      • UMD created additional AuthnNZ config to allow mixed authenticated and unauthenticated access
        
        • Tomcat-specific (valves and shared-session login realm)
      • AuthN can happen in all sorts of ways, not just servlet-container-specific
      • seems possible to configure read-only access in web.xml
      • should be able to enable WebAC with a default "anonymous" user
      • can we remove the authN requirement from web.xml?
        • rely on Apache or other front-end authn that provides principals to Fedora
        • would need some way to (opt-in) specify a default "anonymus" user
   3. Example credentials: URIs vs strings:
      
      • WebAC requires agents to be URIs
      • therefore, example credential usernames should be URIs
      • but there are practical concerns, mostly due to colons (disallowed by HTTP Basic Auth)
      • decision: punt on this (keep example usernames as strings)

Actions

• Bring the proposal to disable versioning using a read-only LDPCv to the Fedora spec editors
• Document UMD's custom authNZ Tomcat configuration (Peter Eichman)