Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dwilcox joins07:49
* MohamedAR joins
* awead joins08:14
* esm_ joins08:18
* MohamedAR leaves08:19
* acoburn1 joins08:26
* acoburn1 leaves08:27
* acoburn1 joins
* acoburn1 leaves08:42
* acoburn joins08:43
* ksclarke joins08:52
* dhlamb joins08:57
* mikeAtUVa joins08:59
<acoburn>awoods: ping
* osmandin joins09:05
* whikloj joins09:17
<acoburn>awoods: about the FedoraResource.getTypes signature
awoods: should it return a List<URI>
awoods: I would note that the FedoraResource.hasType accepts a String09:21
<awoods>acoburn: I would look at how it is currently expected to be used in the codebase.
acoburn: there are a few examples floating around.
<acoburn>awoods: there is one place it is used in the codebase TypeRdfContext09:22
awoods: and it is converted into a triple09:23
awoods: i.e. a URI
<awoods>acoburn: and StreamingBaseHtmlProvider09:24
acoburn: and LDPathTransform09:25
<acoburn>awoods: yes09:26
<awoods>acoburn: and DefaultFilter, FedoraTypesUtils, and NodeTypeRdfContext09:27
<acoburn>awoods: it seems that those all need Strings of the form nt:resource or fedora:Skolem09:29
awoods: in the context of WebAC, however, we need a full URI09:30
awoods: we can't tolerate things like ns001:ImageType
<awoods>acoburn: You are probably right... although ModeShape maintains a NamespaceRegistry for mapping between URIs and prefixes, if that is helpful.09:32
<acoburn>awoods: yes, but do you want the webac module to be accessing the modeshape api?
<awoods>acoburn: no, but if necessary, a copy of the registry Map could get passed in. Not suggesting that, but putting the options on the table.09:33
<acoburn>awoods: I think it is cleanest if the kernel-api returns a list of URIs09:36
awoods: but the issue I'm encountering is that then there is no symmetry between getTypes and hasType
awoods: as I mentioned above, hasType expects jcr types, etc (ldp:DirectContainer, nt:frozenNode)09:37
<awoods>acoburn: Is that "jcr types" or rather short-form prefixed types?09:38
acoburn: List<URI> would we long-form prefixed types, no?
acoburn: List<URI> would be long-form prefixed types, no?
<acoburn>awoods: short-form prefixed types, but I wanted to also point out that it uses jcr types in there
awoods: List<URI> would be the full non-prefixed form09:39
awoods: e.g. http://fedora.info/definitions/v4/repository#Container09:40
<awoods>acoburn: fully qualified, namespaced types, vs. prefixed, namespaced types.09:41
acoburn: anyways, is it the symmetry that is most bothersome?
<acoburn>awoods: yes, the lack of symmetry is concerning
<awoods>acoburn: I am not sure I get your point about "hasType()" expecting/using jcr types.09:42
<acoburn>awoods: there is a translation that happens between types that are prefixed with jcr to types that are prefixed with fedora
awoods: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/TypeRdfContext.java#L9109:43
* MohamedAR joins09:45
<acoburn>awoods: maybe I'm not understanding that code there — but it appears to be translating jcr:someThing to http://fedora.info/definitions/v4/repository#someThing
<awoods>acoburn: yes, that's right.09:46
acoburn: In terms of the symmetry question, we can tackle that in one of two ways...
acoburn: make getTypes() look like hasType(), or vice versa.09:47
<acoburn>awoods: the first approach will not work09:48
awoods: here's why:
awoods: say you insert a resource with some type: foo:StillImage
awoods: but you insert it as n-triples without a @prefix decl
awoods: then fedora sets that namespace as something like ns00109:49
awoods: then, in your webacl, if you define accessToClass as foo:StillImage
awoods: you'd need to access the internal modeshape namespace registry in order to map the results of getTypes() to the rdf:types you want09:50
awoods: that is, getTypes() would respond with ns001:StillImage, and it'd be up to the webac code to figure out that ns001 is the same as foo09:51
awoods: it is true that the FAD has access to the modeshape session().getWorkspace()…, but that seems really messy09:52
<awoods>acoburn: got it. Would it make sense to have getTypes() return List<URI>, and create a symmetric hasExternalType() method?09:53
acoburn: or something
<acoburn>awoods: or a hasType(URI)
awoods: hasType( URI )
<awoods>acoburn: with descriptive javadocs
<acoburn>awoods: yes
<awoods>acoburn: and maybe better javadocs on the existing hasType()09:54
<acoburn>awoods: well the existing javadocs are just plain wrong
<awoods> /**
* Check if this object uses a given mixin
* @param type the given type
* @return a collection of mixin names
boolean hasType(final String type);
<acoburn>awoods: last time I checked a boolean isn't a collection09:55
<awoods>acoburn: About as wrong as it comes
<acoburn>awoods: ok, I'll keep plugging away — I've got the List<URI> getTypes() implemented already09:56
<awoods>acoburn: and we should not be talking about mixins, and the "type" param gives no indication of it being short-form or fully-qualified, and whether JCR or Fedora prefixing is expected.
<acoburn>awoods: I'll add a boolean hasType( URI )
<awoods>acoburn: thanks for hashing it out09:57
<acoburn>awoods: as for the jcr vs. fedora prefixing, should the jcr prefixing be hidden from the API?09:58
awoods: that is, should hasType(String) do the fedora -> jcr translation for you?
<awoods>acoburn: that would make sense from the perspective of a clean API, but the clients of that API would need to be adjusted.09:59
<acoburn>awoods: or are there types (fedora:SkolemNode) that shouldn't be translated to jcr:
* peichman joins
<awoods>acoburn: I do not think the inbound mapping always converts fedora: to jcr:10:02
<acoburn>awoods: right, it seems that it doesn't
awoods: which makes me scratch my head when I see: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/JcrRdfTools.java#L88-L9010:04
awoods: and https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/JcrRdfTools.java#L149-L15410:05
<awoods>acoburn: and the inverse: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/JcrRdfTools.java#L95
acoburn: yes, the functions are there to map back and forth. The question is, are those functions called in all places?10:06
<acoburn>awoods: I'll look10:07
<awoods>acoburn: one way to test it is to create some fedora: namespace properties, then use the /fcr:export to see the native JCR-XML10:08
<acoburn>awoods: if I update a resource with INSERT { <> a fedora:Foo, fedora:Container } WHERE {}10:12
awoods: both fedora:Foo and fedora:Container are translated into jcr:Foo and jcr:Container
<awoods>acoburn: is the same true for properties?
<acoburn>awoods: you mean <> dc:Foo fedora:Bar10:13
<awoods>acoburn:or: INSERT {<> fedora:comment "hello"} WHERE {}
<acoburn>awoods: I just get a 409 conflict10:14
awoods: Could not persist triple containing predicate http://fedora.info/definitions/v4/repository#Comment to node /testns
<awoods>acoburn: not surprising... https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/RdfLexicon.java#L8810:18
acoburn: although it is confusing that we also define "managed properties" again in RdfLexicon: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/RdfLexicon.java#L299-L30810:19
<acoburn>awoods: so I don't want to open up a rats nest with this, especially since I need to be working on the webac stuff
awoods: all I really need for that is getTypes, and I already have that implemented in a local branch
<awoods>acoburn: best turn your head, then.
acoburn: can you summarize your plan?10:20
<acoburn>awoods: so shall I just forget about the hasType( String ) stuff for now. I don't need it. Nor do I need hasType( URI )
awoods: the plan for getTypes?
<awoods>acoburn: yes
acoburn: sounds like you said it above10:21
* mikeAtUVa has a quick question about a F4 use case that I thought was supported... is there any way to create an object, export it, delete the original and import the exported object to have the same URI? Like a basic single resource durable object?
<awoods>acoburn: sounds reasonable... but also please take the opportunity to fix the hasType() javadocs.
mikeAtUVa: I would expect so, if you also delete the tombstone.10:22
<acoburn>awoods: I'll have a PR in just a sec10:23
<awoods>ruebot: any word on getting the Fedora3 dependencies script to work in Travis?10:39
<ruebot>awoods: yes. it will require us (islandora community) to put the maven repo somewhere because we build for 3.5-
<awoods>ruebot: the script does not work?
<ruebot>awoods: ajwagner volunteered to investigate UofT hosting.
awoods: only works for at lest 3.8.110:42
<ajwagner>We have provisional approval to do so; Steve Marks will discuss at leadership today (or has if the call has already happened.)
<ruebot>awoods: older versions require an earlier mulgara dependency.
<awoods>ajwagner: the call is in 45min.10:43
ajwagner: it is on the agenda: https://wiki.duraspace.org/display/FF/2015-09-01+-+Fedora+Leadership+Group+Meeting
<ajwagner>awoods: Gotcha; it was just in my head as "Tuesday Morning"
<awoods>ruebot: older versions can be made available in the same or similar scripts, if needed.10:44
awoods: looks like we'd need 3.6.2, 3.7.0, 3.7.1, and 3.8.110:45
<awoods>ruebot: what would be even more helpful is the list of dependencies required for those releases, that are currently hosted at m2.duraspace.org10:46
ruebot: but if ajwagner and crew are going to take over the hosting, it is moot.10:47
* github-ff joins
[fcrepo4] acoburn opened pull request #899: added getTypes() method (master...fcrepo-1717) http://git.io/vGVEB
* github-ff leaves
<ruebot>awoods: very true. let's see how the UofT situation plays out, then go from there?
<awoods>ruebot: stay tuned10:48
* escowles leaves10:53
<whikloj>acoburn/awoods: you have the hangout link handy10:59
* sbmarks joins11:02
<awoods>acoburn: are you returning?11:04
* acoburn leaves
* acoburn1 joins11:06
* escowles joins11:17
* github-ff joins
[fcrepo-module-auth-rbacl] mohideen opened pull request #23: FCREPO-1714. Moved FedoraUserSecurityContext instantiation to fad. (master...FCREPO-1714) http://git.io/vGVMk
* github-ff leaves
* escowles leaves11:18
* github-ff joins11:20
[fcrepo-module-auth-webac] mohideen opened pull request #9: FCREPO-1714. (master...FCREPO-1714) http://git.io/vGVDr
* github-ff leaves
* escowles joins11:22
<acoburn1>peichman: for the integration tests, this is the class where everything gets set up: https://github.com/fcrepo4/fcrepo-module-auth-rbacl/blob/master/fcrepo-auth-roles-basic/src/test/java/org/fcrepo/auth/roles/basic/integration/AbstractBasicRolesIT.java11:38
peichman: so for our integration tests, we can either just use that data as-is, like the -xacml project (that's how it's currently set up)11:41
<peichman>acoburn1: I guess what I am not getting is how this is testing the repository, since afaict, the RolesFadTestObjectBean objects are just getting created in memory? or am I missing something? (I am probably missing something)
<acoburn1>peichman: … looking through the code11:44
peichman: yes, it looks like the List<RolesFadTestObjectBean> exists only in memory11:47
<whikloj>acoburn1/peichman: which is fine, because you are only testing your code for authentication. Where the permissions are is irrelevant11:49
^^ rather where the "resources are stored is irrelevant"11:50
acoburn1/MohamedAR: This is the abstract class for providing roles (https://goo.gl/wtZXbY), it takes a node and returns Map of all permissions for each role (no filtering). Is that better than pushing them into the WebACAuthorization?
<peichman>acoburn1: okay, I think I am starting to see where the rubber meets the road in org.fcrepo.auth.roles.common.integration.AbstractRolesIT11:52
acoburn1: is one of the issues on the table whether we should try to reuse the RBACL IT suite?
<acoburn1>peichman: I'm not sure it's on the table — at present the integration testing infrastructure uses the RBACL suite11:53
peichman: I'm strongly inclined to keep that infrastructure
<peichman>acoburn1: okay
<acoburn1>peichman: there are a lot of advantages to having a common IT suite across all authZ modules11:54
<peichman>acoburn1: agreed, I just see a lot of code in the AbstractRolesIT that only applies to the RBACL module11:55
things like the fcr:accessroles suffix, and the ?effective query param
<whikloj>peichman: I think fcr:accessroles is really only for RbACL, but acoburn1 can confirm11:56
<acoburn1>peichman: yes, that's very true, but I'm thinking it still makes more sense to override existing code than to reimplement everything from scratch
<acoburn1>whikloj/peichman: yes, I think fcr:accessroles is specific to RbACL
<peichman>acoburn1: are there specific tasks you would like me to take on wrt the WebAC module integration tests? I see it currently has a WebACRolesReaderIT class that extends the AbstractBasicRolesIT12:00
<acoburn1>whikloj/MohamedAR: it seems that a derivative of AccessRolesProvider would be the appropriate point of entry for the FAD
peichman: to start, a WebACRolesWriterIT class would be good12:01
<peichman>acoburn1: okay
<acoburn1>peichman: once we get the FAD _actually_ implemented, then there will be some work to make sure the wiring is all correct in the integration tests12:03
peichman: I'm also not convinced that the existing WebACRolesWriterIT actually checks for authZ access
peichman: since the WebAC FAD returns false for everything12:04
<peichman>acoburn1: make sense12:05
<whikloj>acoburn1/MohamedAR: Do we use the accessRolesProvider to still return a Set<WebACAuthorization> or is the Map<String, List<String>> where to return the permissions?
^^ sorry not return, but compile for the path.12:06
<acoburn1>whikloj: if we use that interface, we'll need to keep that signature
<whikloj>acoburn1: right, but we can extend it12:07
acoburn1: we have to take the path, get the acl, get the Authorizations, compile all permissions and return to accessRolesProvider
<acoburn1>whikloj: exactly. at some point we'll need to transform the Map<String,List> to a Collection<WebACAuth>
whikloj: I'd sort of prefer that that code lives in the WebACRolesProvider class12:08
whikloj: since it acts as a Provider, the FAD can just directly consume what it produces (without having to do additional filtering)12:09
<whikloj>acoburn1: right, so (lacking java8 expertise) could we stream the permissions in and output a Collection<WebACAuth>
<acoburn1>whikloj: yes, that's exactly what we'll do12:10
<whikloj>^^ ok, so I am looking to have a static constructor on the WebACAuth(String, List<String>) ??
<acoburn1>whikloj: here's your opportunity to dip your toes into functional programming
<whikloj>acoburn1: haha
<acoburn1>whikloj: a static constructor?12:11
<whikloj>acoburn1: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/blob/master/src/main/java/org/fcrepo/auth/webac/WebACAuthorization.java
acoburn1: perhaps my lingo is incorrect12:12
<acoburn1>whikloj: what you mean is just a static method
<whikloj>acoburn1: yes, right
<acoburn1>lunch — afk12:14
* acoburn1 leaves12:15
* github-ff joins12:46
[fcrepo-module-auth-webac] whikloj opened pull request #10: Adds webacl:accessControl constant (master...constants-accessControl) http://git.io/vGw4Z
* github-ff leaves
<whikloj>peichman/MohamedAR: ^^ PR just adds the webacl:accessControl to the constants file12:58
* acoburn joins12:59
* esm_ leaves
* github-ff joins13:08
[fcrepo-module-auth-webac] acoburn pushed 2 new commits to master: http://git.io/vGw2z
fcrepo-module-auth-webac/master d33a4b8 Jared Whiklo: Adds webacl:accessControl constant
fcrepo-module-auth-webac/master 7b6af3b Aaron Coburn: Merge pull request #10 from whikloj/constants-accessControl...
* github-ff leaves
<whikloj>acoburn: to use the FedoraResource.getTriples it appears I need a "Context" class, is that just the form the triples come back as?13:10
<acoburn>whikloj: I think the context is used to set the value of the subject13:11
<whikloj>acoburn: wouldn't the subject be the FedoraResource?13:13
^^ or does it also allow for triples where the resource is the object?
<acoburn>whikloj: nevermind, the context seems to define whether the obj is a binary or a container
whikloj: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/FedoraResourceImpl.java#L465-L47113:14
<whikloj>acoburn: right I was looking at that, but not really understanding it at all. What I know is that most calls have some sub-class of NodeRdfContext13:15
acoburn: ala https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/PropertiesRdfContext.java
<acoburn>whikloj: what are you trying to do?13:16
<whikloj>acoburn: get the ldp:contains from the ACL -> Authorizations, then the various triples/properties in each Authorization to fill the WebACAuthorization.13:17
^^ or start at least
<awoods>whikloj: I think acoburn's logic walks up the tree: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/8/files#diff-b437fc88d2f81bdcc2063b89bf2a55eeR13713:18
<acoburn>awoods: that's for finding the ACL, but once that's found, all the child "Authorization" pieces need to be assembled13:19
<acoburn>awoods: basically, whikloj needs the equivalent of setting the Prefer header to include child resources13:20
<whikloj>acoburn: like in a ldp GET request?13:21
<acoburn>whikloj: for example, yes
whikloj: but since we're operating inside the repo, there's no need to make an entire HTTP request
<whikloj>acoburn: no, but it gives me somewhere to start looking in the codebase.13:22
acoburn: and follow the trail to a useful point
if I can understand it, that is
<acoburn>whikloj: take a look here: https://github.com/fcrepo4/fcrepo4/blob/3bee67c3aed9076742e385aa347a36adfe46a907/fcrepo-http-api/src/main/java/org/fcrepo/http/api/ContentExposingResource.java#L19213:23
<acoburn>awoods: is this what you're thinking of for debug logging? https://github.com/fcrepo4/fcrepo4/pull/899/files#diff-7aee50d5030524028026aa94cd75f350R41213:52
<awoods>acoburn: that is fancier than I was expecting, but looks great.13:53
* jgpawletko leaves13:54
* github-ff joins14:09
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/vGwxi
fcrepo4/master b03c4ea Aaron Coburn: Add FedoraResource.getTypes() method...
* github-ff leaves
* github-ff joins14:10
[fcrepo4] awoods closed pull request #899: added getTypes() method (master...fcrepo-1717) http://git.io/vGVEB
* github-ff leaves
<whikloj>awoods/acoburn: question, FedoraResource.getTriples uses an IdentifierConverter, however where we are would not a InternalIdentifierConverter (ie. NamespaceConverter) be more appropriate?14:22
<acoburn>whikloj: awoods will need to answer that one ^^^14:25
<whikloj>acoburn: thanks, I may be in the weeds and he always has a map. :)14:26
* travis-ci joins14:27
fcrepo4/fcrepo4#4019 (master - b03c4ea : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/4629227735a6...b03c4ea93d04
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/78270643
* travis-ci leaves
* github-ff joins14:32
[fcrepo-module-auth-webac] peichman-umd opened pull request #11: Implement an EVERYONE principal in WebACAuthorizationDelegate. (master...everyone-principal) http://git.io/vGrLt
* github-ff leaves
<peichman>created PR for change that adds a getEveryonePrincipal() to WebACAuthorizationDelegate
ran across it when attempting to build and run the integration tests14:33
<awoods>whikloj: the NamespaceConverter probably makes sense, if you are not using/exposing external-facing resource URIs.14:38
<whikloj>awoods: just trying to get the webac triples, so I don't think they will get presented. You'd have to do a GET on the ACL or Authz resource.14:40
awoods: but (and this is assuming I'm right) would that mean we need to modify the getTriples to accept a InternalIdentifierConverter?14:41
^^ https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/models/FedoraResource.java#L153
<awoods>whikloj: I wonder if DefaultIdentifierTranslator could do the trick?14:42
<whikloj>I was looking there too, the note about leaking scared me off14:43
<awoods>whikloj: what note about leaking?
<whikloj>awoods: "Should not be used except in "embedded" deployments in which no publication of translated identifiers is expected!"14:44
<awoods>whikloj: that is the case, no?14:45
<whikloj>awoods: is this an embedded deployment? What does that mean specifically?
<awoods>whikloj: ...since you are not using/exposing external-facing resource URIs.
<whikloj>awoods: ok, fair enough14:46
awoods: then I need the session though, in the WebACAuthorization. Is that ok (from a code cleanliness point of view)?
<awoods>whikloj: it is awful... but is there a way around it? acoburn?14:47
<whikloj>awoods: I don't see anything obvious, just use getProperty?14:49
which seems painful
<acoburn>whikloj: you're trying to get the child resources?
<whikloj>acoburn: child resources and then triples of those child resources. yes14:50
<acoburn>whikloj: so you'll need some sort of IdentifierConverter, which will require a session value, or am I just stating the obvious?14:55
<whikloj>acoburn: that is the issue, do we want the session inside the WebACAuthorization.
<awoods>acoburn/whikloj: does passing in the IdentifierConverter help?14:56
<whikloj>awoods/acoburn: my limited Java experience says it is required to use the FedoraResource.getTriples method14:57
<acoburn>awoods/whikloj: I'd think that would be better, since that's part of -kernel-api
awoods/whikloj: ^^^ I mean passing in the IdentifierConverter instead of a Session14:58
whikloj: here's an example of creating a translator: https://github.com/fcrepo4/fcrepo4/blob/3bee67c3aed9076742e385aa347a36adfe46a907/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraBaseResource.java#L50-L56
<whikloj>acoburn: so pass in an IdentifierConverter when calling the static method from the FAD, did I get that right?14:59
<acoburn>whikloj: yes15:00
<awoods>MohamedAR: are you around? I have not seen your response to the code review comments. https://jira.duraspace.org/browse/FCREPO-171415:20
<MohamedAR>awoods: everything made sense. working on the update.15:24
<awoods>whikloj: In review the wiki: https://wiki.duraspace.org/display/FEDORA4x/WebAC+Authorization+Delegate15:34
* github-ff joins15:35
[fcrepo-webapp-plus] mohideen opened pull request #23: Added webac maven profile (master...webac-profile) http://git.io/vGrwN
* github-ff leaves
<awoods>whikloj: It does not appear that any of your scenarios include "acl:accessToClass" examples.
whikloj: such and example could be useful
whikloj: maybe something along the lines of: public collection, but private master images.15:36
<whikloj>awoods: ok, to confirm accessToClass is only applied at the root level...right?15:37
<awoods>whikloj: I don't think so. That was the old approach.
* osmandin leaves
<whikloj>awoods: gotta check that google doc again.15:38
<awoods>whikloj: Now that we directly associate ACL resources with protected resources, you can have an "accessToClass" Authorization anywhere.
whikloj: ...hanging off of an ACL resource.15:39
<whikloj>awoods: yes, but what does it apply to?
<awoods>whikloj: the protected resource and its children (if they do not have their own ACLs)
<whikloj>awoods: to confirm, resource A has "property" acl:accessControl to ACL resource B15:40
awoods: but ACL resource B only has an accessToClass structure for checking permission to act on resource A?15:41
<awoods>whikloj: that is one possibility, but it seems like the ACL should at least have an accessTo Authorization pointing to A... and throw an exception otherwise.15:43
<acoburn>awoods: no I don't think so15:44
<awoods>whikloj: I was thinking that the ACL would have an accessTo Authorization, and one or more accessToClass Authorizations.
acoburn: what do you think
* MohamedAR leaves
<acoburn>awoods: if the fedora resource A contains the property acl:accessControl pointing to B
* MohamedAR joins
<awoods>escowles: will you have a chance to review this: https://jira.duraspace.org/browse/FCREPO-158115:45
<acoburn>awoods: then only those authorization "children" apply if either they have an accessTo pointing at A OR they have an accessToClass that corresponds to at least one of the classes (rdf:type) of A15:46
<escowles>awoods: i should have time tomorrow morning or thursday morning
<awoods>escowles: anytime this week would be great. thanks!
<acoburn>awoods: so it is possible that there will be no authorization nodes with accessTo pointing at the resource in question15:47
awoods: and only accessToClass in play
<awoods>acoburn: What if none of the accessToClass relate to any of A's types?15:48
<acoburn>awoods: then the ACL doesn't apply
<awoods>acoburn: the access denied?
acoburn: then access denied?
* dwilcox leaves
<acoburn>awoods: correct
<awoods>acoburn: I am good with that.15:49
acoburn/whikloj: my scenario is slightly different
Resource A is a collection, with child resources
Resource B is an ACL to which A points
maybe the ACL only has one Authorization... accessToClass15:50
Requests on one of the child resources will check agains that accessToClass, no?
<acoburn>awoods: correct15:51
awoods: my understanding is this:
<awoods>acoburn: good
<whikloj>those sound the same to me
<awoods>similar, yes, whikloj
and if none of the accessToClass classes apply to a child... access denied.
<acoburn>requests for the child resource will walk the tree up until an ACL is found
<awoods>acoburn: that is the question15:52
<acoburn>if that ACL has no relevant accessTo or accessToClasses, then access is denied
<awoods>acoburn: will the walking stop when an ACL is found, or when an ACL that applies is found?
<whikloj>to the root, then access denied
<acoburn>awoods: when the first ACL is found
<acoburn>whikloj: the FAD may stop before it gets to the root15:53
<awoods>acoburn: if it finds any ACL on the way
<whikloj>acoburn: agreed, but if there is no ACL then it goes to root
<acoburn>awoods: correct15:54
whikloj: correct
<awoods>whikloj: correct
<acoburn>awoods/whikloj: one question that I'm sure we've discussed (but I can't remember the answer to) --
if there is a collection object with an ACL
and that ACL has an accessTo clause pointing at the collection15:55
how is access handled for the children of that collection?
does the accessTo no apply to the children?
does the accessTo not apply to the children?
<awoods>acoburn: applies makes sense to me.15:56
<acoburn>awoods: that's what I thought
<awoods>acoburn: It is like saying: "this collection is private"
acoburn: we need to document all of these nuances.15:57
<whikloj>acoburn: see I thought it did, but now I think the logic is: child hasAcl -no-> parent hasAcl -yes-> ACL has accessToClass matching child -no-> apply permissions for accessTo parent
<awoods>whikloj: that flows sounds right. Is it different than what acoburn and I just agreed on?15:58
<whikloj>awoods: I'm not sure, the nuance of IRC makes a full thought hard to follow.
^^ but if you say it is, then I am happy15:59
<awoods>whikloj: it looks like the same flow to me. Thoughts acoburn?
<acoburn>whikloj: that sounds like what awoods and I just said
<whikloj>acoburn/awoods: ok, I'm going to push a branch to my fork with what little I think I accomplished and look at adding another Sparql recipe
* dhlamb leaves16:02
<MohamedAR>whiloj: I was thinking that accessTo parent privilege comes before accessToClass. child hasAcl -no-> parent hasAcl -yes-> user has accessTo parent -no-> ACL has accessToClass matching child16:04
whikloj: ^^16:05
whikloj: acoburn: awoods: wrong?16:06
<whikloj>MohamedAR: so if you had access to the parent you get those permissions for the child?
<awoods>MohamedAR: an accessToClass that matches a child seems more specific than an accessTo on the parent.
<MohamedAR>whikloj: I was thinking so.16:07
awoods: accepted.
<awoods>MohamedAR: I saw a PR from you, but no ticket update.
MohamedAR: is the ticket ready for review?
<MohamedAR>awoods: need to fix the rbacl PR.16:08
<awoods>MohamedAR: the PR related to webapp-plus
<MohamedAR>awoods: I will create a ticket for it. I thought ticket needed only for fcrepo. So, it's everything except webac work?16:11
<awoods>MohamedAR: yes, everything needs tickets except webac... for now16:12
<MohamedAR>awoods: cool
<awoods>MohamedAR/peichman: see http://irclogs.fcrepo.org/2015-08-28.html @12:3216:14
<whikloj>awoods: new Sparql: https://wiki.duraspace.org/display/FEDORA4x/WebAC+Authorization+Delegate16:17
<awoods>whikloj: minor note that just occurred to me...16:18
whikloj: In all of your examples you start with: Acl.ttl = <> a ldp:BasicContainer; rdf:type ???:WebAcl .16:19
<whikloj>acoburn: this is my first crack at the WebACAuth Impl, my stream understanding is weak. https://github.com/whikloj/fcrepo-module-auth-webac/blob/WebACAuthorizationImpl/src/main/java/org/fcrepo/auth/webac/WebACAuthorizationImpl.java
awoods: yes
<awoods>whikloj: since rdf:type is synonymous with "a", and since you get a BasicContainer by default, this could be:
whikloj: Acl.ttl = <> a ???:WebAcl .16:20
<MohamedAR>awoods: peichman did notify me in local chat - I misread it to be for the FedoraUserSecurityContext
<whikloj>awoods: oh okay, didn't know that
awoods: I'll update them
<awoods>MohamedAR: np16:21
peichman: thanks
<whikloj>awoods: however we do still need to either find or make an ontology to use for that
<awoods>whikloj: indeed. Probably "make" at this point.
whikloj: if you are in the wiki updating, you can probably drop the declaration for "a ldp:RDFSource"16:22
whikloj: as well as change "rdf:type acl:Authorization" to "a acl:Authorization"
<whikloj>awoods: right16:23
<awoods>whikloj: looking at your newest wiki recipe16:24
whikloj: I think collection children of all types will be public-readable.16:25
whikloj: certainly ex:publicImage children will be public-readable
whikloj: ...well. nevermind.
<awoods>since the acl:agent does not match.
<whikloj>I'm going to strip out extraneous prefixes from the Sparql recipes now too
<awoods>whikloj: strip'em16:27
<whikloj>awoods: updated wiki documentation16:34
<awoods>whikloj: looks good16:36
* whikloj leaves17:00
* mikeAtUVa leaves17:05
* acoburn leaves17:17
* peichman leaves17:39
* ksclarke leaves17:50
* ksclarke joins17:59
* jgpawletko joins18:16
* github-ff joins18:20
[fcrepo4-release-tests] awoods opened pull request #16: Fix broken sparql-recipes (master...fcrepo-1719) http://git.io/vGoVo
* github-ff leaves
* MohamedAR leaves18:25
* the_mgt_ joins19:16
* the_mgt leaves19:20
* awead leaves19:59
* ksclarke leaves20:13
* dhlamb joins21:44
* dhlamb leaves21:45
* dhlamb joins21:46
* dhlamb leaves23:30

Generated by Sualtam