[OTDev] List of all resources and authentication

Nina Jeliazkova nina at acad.bg
Fri Jun 18 12:42:11 CEST 2010


Hi Pantelis, All,

chung wrote:
> Hello Nina, 
>   I think it would be both more efficient for the server (because it
> would provide shorter representations) and for the client (to be able to
> view only the resources to which it has access) if the services return
> only a URI list of resources at which the client has access. Otherwise
> the services would have to return very long lists of URIs or even RDF
> documents. 
>   
IMHO this is better handled by adopting a search functionality -
e.g.retrieve only objects which comply to certain criteria (user or
group ownership) and should be independent of AA. 
I am kind of reluctant to the idea of duplicating resource - users
relationships in services, for the obvious reason one can issue OpenSSO
call to change this relationship, without ever informing the service.
Then the service will have outdated information, which will be difficult
to synchronize.

>From OpenSSO side , I am afraid there is no easy way to retrieve list of
objects of particular type that "belongs" to particular user - Andreas
am I right?
>   However if we decide to return the complete list I think it would be
> good practice if clients requested only URI lists and not RDFs for the
> sake of shorter representations. Recall that RDF representations contain
> all information about the underlying resources, for example if you ask
> for an RDF/XML representation of all model you can see every model's
> independent and dependent variables etc.
>   
It will be valid to have subset of RDF representation, e.g. when
retrieving datasets , only metadata is retrieved, not all compounds and
properties. Same could be done for models.

Even if model variables are retrieved, these are only links, not their
representation.

Regards,
Nina
>
> Best regards,
> Pantelis
>
>
> --------------------------------------------------
>
> New Book: Teach yourself C in 45 years, Volume I.
> Special offers for life prisoners ;)
>
>
> On Fri, 2010-06-18 at 12:36 +0300, Nina Jeliazkova wrote:
>   
>> Hi,
>>
>> Good question.  The easiest workaround would be to return URIs of all
>> resources, regardless of the ownership/policy - if the user wants to
>> retrieve representation of the  particular resource, then the
>> authorisation applies.  This will not break protection of confidential
>> resources, since the client will get only links, not resources
>> themselves.  And this is how typical web page works as well - you can
>> see the links, but accessing the links might require AA.
>>
>> In fact, retrieving list of resources should rely on the policy for the
>> top level resource (e.g. /model )  , which might have GET allowed for
>> everybody.
>>
>> Best regards,
>> Nina
>>
>> chung wrote:
>>     
>>> Hi All, 
>>>   If a user needs a list of all models or datasets (either a URI list or
>>> an RDF document) is the service supposed to return only his resources
>>> neglecting all other or list all resources to which the user has access?
>>>
>>>  In the first case I guess some identifier for the user has to be saved
>>> in the database (e.g. bob at opentox.org). Checking all resources in the
>>> database for authorization one by one I think is out of the question for
>>> this would be a bottleneck. Maybe it is worth think about how can the
>>> client obtain a list of all resources it can access which of course
>>> might have been created by other users.
>>>
>>> Best regards,
>>> Pantelis
>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>   
>>>       
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>>     
>
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>   




More information about the Development mailing list