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.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

User Story #156 (closed)

Opened 18 years ago

Closed 18 years ago

Implement "System-Types" (Experimenter,Event,...) which can't be created by all users.

Reported by: jamoore Owned by: jamoore
Priority: blocker Milestone: 3.0-M3
Component: Security Keywords: model, dsl, iteration2
Cc: Story Points: n.a.
Sprint: n.a. Importance: n.a.
Total Remaining Time: n.a. Estimated Remaining Time: n.a.

Description

It was assumed that ITypes' functionality was needed to implement System-Types, but it should be doable with a single interface (ome.api.SystemTypes). This can then be implemented before the DSL is ported to annotations (#96). In combination with the change made for #52 (allowing annotations from different users when running as root), we are approaching the basic building stones needed for Security.

Change History (8)

comment:1 Changed 18 years ago by jmoore

  • Priority changed from minor to major

Another requirement for System-Types may be that instances are also not editable by users regardless of the other Permissions set. Such a use case exists in the Rendering Engine where there should be no alterations of the rendering settings through IUpdate or other mechanisms. RenderingBean? can use a @RunAs? annotation to set the current role to "system", so that system types can be edited.

This could be solved through a different mechanism and then the System-Types feature remains quite simple.

comment:2 Changed 18 years ago by jmoore

  • Milestone changed from 3.0-M2 to 3.0-M3
  • Priority changed from major to blocker

comment:3 Changed 18 years ago by jmoore

  • Keywords iteration1 added

This is at the basis of much of our security. Let's get it done soon.

comment:4 Changed 18 years ago by jmoore

Not just the non-creation but also the updating of System-Types can be controlled. This should be added to UpdateFilter & SecuritySystem such that no time is spent trying to verify updates to, e.g., Experimenter (a la checkManagedState), rather that it simply passes through and if it ends up in an UpdateEvent then an exception is thrown.

comment:5 Changed 18 years ago by jmoore

r768 added the definition of SystemTypes (even if this needs to be moved to ITypes), but the actual catching of their creation/update still needs work. Most of iteration1 was spent preparing for these catches, by pushing the checks on transient and managed object (specifically their details) into the Hibernate EventListeners rather than in UpdateFilter, which turned out to be extremely tricky, requiring the addition of the findDirty check in OmeroInterceptor.

Planning on pushing this to the next iteration.

comment:6 Changed 18 years ago by jmoore

  • Keywords iteration2 added; iteration1 removed

comment:7 Changed 18 years ago by jmoore

r790 introduces several tests that check System-Types. Looking good.

comment:8 Changed 18 years ago by jmoore

  • Resolution set to fixed
  • Status changed from new to closed

With the changes of r812 and r827 System-Types are fully implemented. From the server side, there are some issues with when the objects get created as whom, but that is less of a concern. Clients can no longer create the security-related types ( Experimenter, ExperimenterGroup, GroupExperimenterMap, Event,...) nor IEnums (#157). This is all now checked in the ACLEventListener.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

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

We're Hiring!