Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You're right, securing a page and securing elements is different. </p> <p>In my opinion and in practice, I think tying any code to a role or user is actually the wrong approach. Instead, tie permissions to elements and pages - then tie roles to those permissions. And of course, users are assigned roles.</p> <p>It is important to have all three :</p> <ol> <li>Users </li> <li>Roles</li> <li>Permissions &lt;-- this is what you're missing</li> </ol> <p>Permissions are what secure elements and pages, <strong>not roles or users</strong> Your code should have no clue (because it doesn't need to) what users or roles there are - just names of permissions.</p> <p>When a user logs in, I grab their role(s). Then I grab all the permissions that are assigned to those roles (simply a list of string values).</p> <p>For example, on a page I might have : </p> <ul> <li>Add item</li> <li>View item</li> <li>Delete item</li> </ul> <p>When I code that page, I actually secure each of those elements with permission strings named similar ( addItem, viewItem, deleteItem). </p> <pre><code>&lt;cfif listContainsNoCase( session.permissions, 'addItem' )&gt; &lt;!--- code to add item ---&gt; &lt;/cfif&gt; </code></pre> <p>(Note: I recommend using a custom tag or function for this, but for purposes of an example, the above works fine).</p> <p>If you do it this way, it provides maximum flexibility and abstraction. If you secure elements based off of roles, you limit yourself : </p> <ul> <li>Adding new roles will require a lot of code changes!</li> <li>Changing permissions between roles requires a lot of code changes!</li> </ul> <p>If you do it as mentioned above, you will never need to change your security code within the code base, because "addItem" permission should always be on the "add item" logic, right? :)</p> <p>Now if you happen to need to create a "manager" type role, that has all the user roles and a select few admin rights, you simply create that role, and assign it the correct permissions (maybe addItem and editItem, but not deleteItem). Bam! Now I have a manager role to assign to users with <em>no code changes</em>!</p> <p>If I had sprinkled my code with "is user this role" type of stuff - I would have to go edit my code everywhere to allow my new role "manager" - yuck! </p> <p>Make sense?</p> <p>=)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

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