Hi Alexander,
In data mercoledì, 22 agosto 2012 14.28:47, Alexander Wagner ha scritto:
> Yes. It seems I see a bit clearer now.
>
> Let me summarize if I get it right. viewrestrdoc gets a
> parameter. This parameter is a free form string, I can use
> whatever I want here. Then I can add the action viewrestrdoc
> to a role and specify this very string to get some access to
> the full text in a way orthogonal to the collection
> association. I'm not yet sure if this solves an issue for
> our case but options are always interesting. ;)
Almost. viewrestrdoc is not orthogonal. If a record belong to a restricted
collection (via viewrestrcoll) and it has restricted document (via
viewrestrdoc), a user must be authorized *both* to the collection *and* to the
document: i.e. documents are implicitly restricted at least as the collection
the corresponding record belongs to. See also below.
> Let me make a real world example what we have. Some Marc
> stub:
>
> 001 123
> 245 $aMy important paper
> 980 $aI:(DE-Juel1)ZB-20090406
> 980 $aVDB
>
> Now we have a collection named ZB-20090406 with
> collection:"I:(DE-Juel1)ZB-20090406" as query, so this
> record belongs to this very collection. And a collection
> named VDB with collection:"VDB" as query.
>
> Now I want collection ZB-20090406 to be restricted, so I set
> up a role I-ZB-20090406 with these firerules:
>
> allow groups 'I:(DE-Juel1)ZB-20090406 [FZJ eMail-Account]'
> allow groups 'STAFF'
>
> And I add viewrestrcol with parameter ZB-20090406, ie. the
> colletctions internal name.
Wow, you use quite intricate names in your institution :-)
> All this magic restricts access to my collection
> ZB-20090406 to all users belonging to the group
> 'I:(DE-Juel1)ZB-20090406 [FZJ eMail-Account]' (this is from
> LDAP auth) and additionally allows all users in the group
> STAFF access to the records of this collection and as such
> to my very important record 123 above.
Correct.
> If I now attach a pdf to my record 123 this is, however, not
> restricted till now.
Not correct. It restricted as the record, i.e. you still need to be authorized
to the "ZB-20090406" collection in order to download/see it.
> Only the record as such has a
> restriction, but if someone would know the direct url to the
> pdf no restriction would apply. (Is this right?)
Nope :-) We really enforce the restriction. Otherwise Google or a malicious
user could have happily accessed any restricted record by simply crawling
Invenio for all the existing recids.
> Now, you say I could set the status of this document to say
> "I:(DE-Juel1)ZB-20090406" in some way I don't yet know, but
> surely our websubmit guru (aka Tomek) knows and could pass
> this string to the viewrestrdoc action. Add this action to
> my above defined role could gives access to all users of my
> group I-ZB-20090406 to the document.
Well, your collection are properly set and authorized as you mention above
then I think you have no further need to also restrict documents.
> I could shortcut much of this fuzz woudn't be there the open
> collection VDB above which should actually see the
> bibliographic record, but may not (yet) have access to the
> full text for some reasons.
>
> > and that's why we extended the authorization of BibDoc to
> > also directly allow explicit roles/fireroles etc.
>
> This is the $r-subfield in the fft-tag. Right?
Right.
> This is what we actually do. We set up a collection for each
> institute (as outlined above) and add a role with actions
> attached.
>
> > So if the collection "foo" should be authorized
> > to group X, Y, Z, you can simply authorize these group
> > (for which it exists each time a role) explicitly via
> > "viewrestrcoll" action.
>
> Right. But then I do not yet have the full texts restricted
> but only the bibliographic record.
No, no, also the fulltext :-)
> > In this way it will suffice for a
> > person to be member of either X or Y or Z, and
> > consequently belong to the corresponding role to access
> > the collection, and all the inner records and documents.
> > Documents are automatically protected to anybody not
> > authorized to the collection - but the owner of the record
> > (who always can access attached documents).
>
> This would suffice indeed if we didn't have an open
> collection that our records belong to in many cases. You
> might remember that you prepared a patch for us that allows
> for "if any rule matches" in the firerules block.
Unfortunately :-) But I in the CFG_WEBSEARCH_VIEWRESTRCOLL_POLICY feature we
implemented for you public collections were not considered. I.e. in the any-
version, if a record belongs to the restricted collection A, the restricted
collection B and the public collection C, then the user must at least be
authorized to access the either collection A or collection B (regardless of C
being public).
> Done :) I think we have everything in place except the the
> doc restrictions (which wouln't be necessary in the first
> place if Science would really be free <scnr> ;)
Eheh, well still you can use Invenio to store more than scientific documents
:-)
> This is a bit more involved here as we acutally need to
> harvest the LDAP (or a similar) system and also need to
> generate a bunch of "bibliographic" records thereof. You
> probably remember our discussion @CERN about authority
> control where we use authority records living in MARC
> instead of knowledge bases. (I think we should definitely
> take a cup of tea over these issues in the near future, ie.
> as soon as our stuff went publicly online.)
>
> Anyway, basically we need to set up those records in this
> step as well. For those following this far and wondering
> "why the h... does he use so complex naming schemes", this
> is the very reason: mapping institute histories, hierarchies
> and rights with a bunch of collections living in t=now and
> not valid for t=tomorrow in a managable way.
:-) BTW does the BEFORE/AFTER syntax in FireRole help you in any way? (i.e.
you can have time-based authorizations too).
Cheers!
Sam
--
Samuele Kaplun
Invenio Developer ** <http://invenio-software.org/>
