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"

Task #235 (closed)

Opened 16 years ago

Closed 16 years ago

Should all users of SecuritySystem be given a Token

Reported by: jamoore Owned by: jamoore
Priority: minor Milestone: 3.0-M3
Component: Security Version: 3.0-M3
Keywords: tokens, secsys,securitymanager,iteration5 Cc:
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

or at least all users of those methods which (could) require tokens. For example, the method:

   securitySystem.addLog();

used by EventLogListener could take a Token that was injected into the EventLogListener instance.

However, before we go to far down this road, we may just want to use the Java SecurityManager.

Change History (5)

comment:1 Changed 16 years ago by jmoore

r786 introduces an extraordinarily simple Token class. Actually the simplest possible class:

   public class Token {}

It's completely inert (so even subclassing it should be harmless). Tokens can be instantiated but should be kept in a private field and never shared, and used to represent a loose form of ownership.

Do we need something more like this?
http://java.sun.com/docs/books/tutorial/security1.2/userperm/index.html

comment:2 Changed 16 years ago by jmoore

r812 takes this a step further an introduces a SecureAction which temporarily adds a token to an object.

comment:3 Changed 16 years ago by jmoore

merge() causes a copy of our IObjects to be made. This breaks the token concept. Currently, quick-fixing by allowing a hook into SecuritySystem from MergeEventListener but this is becoming nasty. A ThreadLocal approach similar to SecurityManager maybe better (though there are issues with object identity on merge. Perhaps #54 UUIDs again? )

comment:4 Changed 16 years ago by jmoore

Now treating this as the GraphHolder/Token umbrella: r823 fixes GraphHolder serialization. Can still be optimized to lazily load now that the final is gone.

comment:5 Changed 16 years ago by jmoore

  • Keywords iteration5 added
  • Resolution set to wontfix
  • Status changed from new to closed

Rescheduling with #328, but closing with will not implement. The token functionality is sufficient as it stands, but there's no benefit to giving out more tokens ; the interfaces just need to be improved.

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.63353 sec.)

We're Hiring!