Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.

Changes between Initial Version and Version 4 of Ticket #3527


Ignore:
Timestamp:
03/01/12 15:58:51 (12 years ago)
Author:
jmoore
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3527

    • Property Status changed from new to accepted
    • Property Cc omero-team@… added
    • Property Component changed from General to Security
    • Property Summary changed from Initial public data work to Call context support ("omero.group", "omero.user", etc.)
    • Property Milestone changed from OMERO-Beta4.3 to OMERO-Beta4.4
  • Ticket #3527 – Description

    initial v4  
     1== Motivation == 
     2 
     3An initial phase of the public data work (#1733) is to once again allow querying over multiple groups, without requiring a user to create multiple sessions. This was disabled as we moved to group-based permissions (#1434 et al) in order to prevent clients from attempting to cross-link data between groups. This restriction, however, is too extreme, causing various forms of workarounds. 
     4 
     5== Sample usage == 
     6 
     7The call context of each remote method invocation is the passed via the code-generated last argument of all Ice methods. For a method defined as: 
    18{{{ 
    2 == Day 3 (Wed., the 17th) == 
     9   interface IQuery { 
     10      IObject get(string type, long id); 
     11   }; 
     12}}} 
     13in slice, Ice will generate both methods: 
     14{{{ 
     15      IQueryPrx.get(String, long); 
     16      IQueryPrx.get(String, long, Map<String, String>); 
     17}}} 
     18for OmeroJava, or in OmeroPy and OmeroCpp an optional argument: 
     19{{{ 
     20      IQueryPrx.get(type, id, context=None) 
     21}}} 
    322 
    4 Public data disussion 
    5     * Implementation options that were discussed 
    6         * Using the "user" group, i.e. the common space 
    7         * One share per image or one big share 
    8         * Multiple public groups v. one public group 
    9         * Using world flag per row (in addition to group) 
    10         * Subgroups 
    11         * Copy to a public server 
    12         * ACLs 
    13     * Requirements that were discussed 
    14         * Google-able 
    15         * Optional annotations 
    16         * Object URL 
    17         * Collaborative containers 
    18         * Unpublish 
    19         * in-group, between-group, public sharing 
    20         * protecting binary data 
    21     * Other items 
    22         * @@check share performance 
    23         * adding licensing/copyright information on "publication" 
    24         * any form of writing or linking on public data? 
    25         * refactor or rollback or add shares to Insight. Needs UI investigation. 
    26     * Two primary solutions to be investigated 
    27         * Use chgrp for collaboration and row-level world-read for publishing 
    28         * Subgroups 
     23For each of the types of context outlined below, an entry can be added to this map in order to effect the processing: 
     24{{{ 
     25   Map<String, String> callContext = new HashMap<String, String>(); 
     26   callContext.put("omero.group", "-1"); 
     27   queryPrx.get("Image", 1L, callContext); 
    2928}}} 
     29 
     30=== "omero.group" === 
     31 
     32The group context is usable by any user to change, thread-safely, the group that they are logged in to '''for the duration of one method call'''. Admins can use any group id value to log in to that group: 
     33{{{ 
     34   callContext.put("omero.group", someUsersGroup); 
     35}}} 
     36or "-1" in order to log in to all groups: 
     37{{{ 
     38   callContext.put("omero.group", "-1"); 
     39}}} 
     40 
     41Regular users (non-admins) can set the value to any group that they are a member of or "-1", meaning "all of my groups". 
     42 
     43=== "omero.share" === 
     44 
     45Similar to "omero.group", any member of a share can choose the id of the share which should be made active for the current method call. "-1" is supported for admins, meaning all data, but not for non-admins due to the complexity of determining what is contained in the given share. 
     46 
     47Both "omero.group" and "omero.share" work identically to calling `ServiceFactoryPrx.setSecurityContext` with the given id value, except for the fact that the value does not persist beyond the single method call. 
     48 
     49=== "omero.user" === 
     50 
     51Somewhat differently, the user context is usable only by admins in order to perform a '''sudo'''-like operation. If an admin would like to create an object for another user, or see what a query would return for such a user, then "omero.user" can be passed with a non-negative id. ("-1" has no meaning in this context). One stipulation is that the "omero.group" setting should also be set to match a group that the user is a member of, otherwise the user will receive a `SecurityViolation` for trying to access an improper group. 
     52 
     53== History == 
     54 
     55Initial work for this type of functionality took place in #2199. The chosen solution at that time was to use the "omero.group" setting as above, but internally to set the share id of the session to "-1" meaning make all data readable. This was only usable by admins. 

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.13348 sec.)

We're Hiring!