Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've beat my head against this wall on several occasions.</p> <p>The best solution I've come to was to model everything in a tree hierarchy, where every domain class is an branch in the tree, and instances are leaves of that branch. Leaves can have veins if you need to secure parts of instances. Each branch has its own assigned actions (such as "Read", "Write", "Delete", "Publish"). Use the same hierarchy for security but the root then becomes a user or a group. You end up with a structure like:</p> <pre><code>&lt;domain&gt; Project |- &lt;class&gt; Person | |- &lt;instance&gt; John | |- &lt;instance&gt; Mary |- &lt;class&gt; FormX | |- &lt;instance&gt; John's Leave Form ... </code></pre> <p>and to apply security you may have a group named Administrators who can do stuff with people:</p> <pre><code>&lt;group&gt; Administrators |- &lt;class&gt; Person: actions (Read, Create, Update, Suspend) </code></pre> <p>and an office admin who can process forms and make new people:</p> <pre><code>&lt;group&gt; Office Administrator |- &lt;class&gt; Person: actions (Create) |- &lt;class&gt; FormX: actions (Approve, Deny) </code></pre> <p>and then John can do stuff with his own profile:</p> <pre><code>&lt;user&gt; John |- &lt;class&gt; Person | |- &lt;instance&gt; John: actions (Edit) </code></pre> <p>When I implemented this structure it was using C# and SQL Server 2000 so I was able to use the XML schema data type and perform security queries against the database or [as more often the case] merge a person's security profile into a single tree to determine what rights someone has to an instance, class, or other (I had <code>&lt;group&gt;</code>s - not security groups - in the domain above class for ease of maintenance).</p> <p>Its also important to include - though I did not illustrate it - that each action was a permission, not a boolean, where the permission values were <code>{ Allow, None, Deny }</code> with Allow granting access to that verb except when explicitly denied, None neither allowing nor denying, and Deny preventing access no matter what.</p> <p>An advantage you gain from this structure is that you can add other types of branches into it, such as a data driven taxonomy, and still use the same API.</p> <p>In my specific implementation I added custom metadata attributes to methods and properties and I had to invoke a <code>SecurityManager.Test</code> method in each "secured" function as a final layer of authorization (<code>SecurityManager.Test</code> was normally invoked to determine whether to show or hide pieces of a form, and determine which buttons were visible in the UI). Now that I am aware of it if I ever have to implement the same thing again, I'll use <a href="http://www.postsharp.org/" rel="nofollow noreferrer">PostSharp</a> to inject security tests into my domain model.</p>
    singulars
    1. This table or related slice is empty.
    1. PORestricting access to objects in an application
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. UScfeduke
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PORestricting access to objects in an application
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYes, that's close to how I've implemented this as well, although your implementation seems more organized and complete. I had an idea to use attributes instead of what you call SecurityManager.Test(), but the PostSharp-idea is great! Thanks, you've helped a lot!
      singulars
      1. PO
      1. USKarl
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload