Looking for Good Database Rules Implementation

As the subject indicates, I am looking for how others are doing this.

I have a fair idea what I need, but not sure how to approach this in the ColdBox framework.

I am looking at getting the users permission role (view, credit, edit, delete) based on the view being displayed as well as the handler being run. I am not sure how many people are actually out there using something like this, but would like to see how others are approaching or have approached this.

Regards,

Andrew Scott

http://www.andyscott.id.au/

I just finished a little experiment using metadata injection that
looks like it might serve pretty well.

In the handler

<cffunction name="foo" .... permissions="read,write,delete">

I used a simple interceptor to read the handler metadata and match
items in the user's permission structure. In the example above I'd be
seeing whether the user has keys handler.foo.read, handler.foo.write
and handler.foo.delete. If anything is missing then it will throw to a
"no you can't do that" event.

I'm going to port this to a centralised definition file and see what
"looks" nicer, but ultimately the interceptor route seems to be the
way to go

Andrew,

I'm not sure if what I do is "Best Practice" - but, here it is:
There are a lot of ways to do this. I guess it would depend on your
method of passing vars.
Cookies or RC.

1.) Under "views" I would make a folder called "Users".
     - All my views will go here.
2.) Then I create one "handler" called "Users.cfc"
     - Inside the handler I would put the following ...

  <!--- index func --->
  <cffunction name="index" output="false" hint="index">
    <cfargument name="event">
    <cfset var rc = event.getCollection()>

    <!--- Here we can either use cookies that have been set
        or getVar functions --->

    <cfif rc.Edit eq true >
      <cfset event.setView("Users/Edit")>
    </cfif>
    <cfif rc.Edit eq true >
      <cfset event.setView("Users/Edit")>
    </cfif>

    <cfset event.setView("Users/index")>
  </cffunction>

  <!--- View func --->
  <cffunction name="View" output="false" hint="View">
    <cfargument name="event">
    <cfset var rc = event.getCollection()>

    <cfset event.setView("Users/View")>
  </cffunction>

  <!--- Edit func --->
  <cffunction name="Edit" output="false" hint="Edit">
    <cfargument name="event">
    <cfset var rc = event.getCollection()>

    <cfset event.setView("Users/Edit")>
  </cffunction>

So instead of having 1 "handler" and its subsequent view folder for
"Edit", "View", etc.

I use 1 handler to control all the related views.

This is easily done in ColdfuionBuilder with ColldBox Utilities. When
you make a handler - replace the word "index" witth
"index,View,Edit" (with no spaces). Make sure that you set the "View
Folder" field proplerly (views/Users).

In this case, I would have 1 handler control giving access to multiple
pages like "Edit" and "View".

Cheers, but what I am looking for is the routes definition setup in the
database itself. How is it being applied to different views and handlers
etc. We have an administration section that we can add programs, groups
etc., then tie this down via roles and permissions.

I am wanting to convert this to ColdBox and use the Security Interceptor to
intercept the call and check it against the database.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of oobi
Sent: Thursday, 28 October 2010 4:05 PM
To: ColdBox Platform
Subject: [coldbox:6400] Re: Looking for Good Database Rules
Implementation

I just finished a little experiment using metadata injection that looks

like it

might serve pretty well.

In the handler

<cffunction name="foo" .... permissions="read,write,delete">

I used a simple interceptor to read the handler metadata and match items

in

the user's permission structure. In the example above I'd be seeing

whether

the user has keys handler.foo.read, handler.foo.write and
handler.foo.delete. If anything is missing then it will throw to a "no you

can't

do that" event.

I'm going to port this to a centralised definition file and see what

"looks"

Would you mind sharing your code on this interceptor, I might still look at
this for the permissions after the security is done.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of oobi
Sent: Thursday, 28 October 2010 4:05 PM
To: ColdBox Platform
Subject: [coldbox:6400] Re: Looking for Good Database Rules
Implementation

I just finished a little experiment using metadata injection that looks

like it

might serve pretty well.

In the handler

<cffunction name="foo" .... permissions="read,write,delete">

I used a simple interceptor to read the handler metadata and match items

in

the user's permission structure. In the example above I'd be seeing

whether

the user has keys handler.foo.read, handler.foo.write and
handler.foo.delete. If anything is missing then it will throw to a "no you

can't

do that" event.

I'm going to port this to a centralised definition file and see what

"looks"

Andrew,

Ok - I think I understand.

In my app I had one table. It defined all rolls in the app.
   - Roll 1 = Registered User,
   - Roll 2 = Admin. Level 1
   - Roll 3 = Admin. Level 2
   - Roll 4 = Admin. Level 3

I then added 2 more table
  - Table: Users
  - Table: Admin

Bother these tables referenced the Roll Table.

For added security, I used RC.

After login was successful, I had the database return to me 2 things:
  - User ID
  - User Roll

Both I would assisgn into RC.
  - <cfset rc.rolls = #rolls#>
  - <cfset rc.user = #userID#>

Within the "handler" - the value of rc.rolls would determine:
   - which menu options were displayed.
   - which page was displayed.

This is neither here nor there, but I've been playing with using
ValidateThis to do authorization.

I like the idea of conditionals and whatnot.

We'll see if anything cool comes from it.

:Den

Sorry guys, I appreciated all your comments but I forgot to include the most
basic requirement. This also needs to work with routes, it is the routes and
roles/permissions I am more interested in.

Although I still like to explore the annotation concept further as well.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Rus Russell
Sent: Thursday, 28 October 2010 11:01 PM
To: ColdBox Platform
Subject: [coldbox:6405] Re: Looking for Good Database Rules
Implementation

Andrew,

Ok - I think I understand.

In my app I had one table. It defined all rolls in the app.
   - Roll 1 = Registered User,
   - Roll 2 = Admin. Level 1
   - Roll 3 = Admin. Level 2
   - Roll 4 = Admin. Level 3

I then added 2 more table
  - Table: Users
  - Table: Admin

Bother these tables referenced the Roll Table.

For added security, I used RC.

After login was successful, I had the database return to me 2 things:
  - User ID
  - User Roll

Both I would assisgn into RC.
  - <cfset rc.rolls = #rolls#>
  - <cfset rc.user = #userID#>

Within the "handler" - the value of rc.rolls would determine:
   - which menu options were displayed.
   - which page was displayed.

---------------------
Just before each page is displayed, I use the database once more.
I send the values of "rc.roll" and "rc.userID" to the database to verify

that the

current user does, indeed have access to this page.

At this point it can get more complicated depending on the type of

security

The problem with this is that the event gets run, then the validation takes
place, with the routes and security interceptor it well intercepts checks
then redirects if it has too.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of denstar
Sent: Friday, 29 October 2010 7:06 AM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6414] Re: Looking for Good Database Rules
Implementation

This is neither here nor there, but I've been playing with using

ValidateThis to

Theoretically, you could use ValidateThis in an interceptor. Maybe
using the route, or part of it, as the context?

I just kinda like the idea of contexts and conditions.

It was just a random thought that sprang to mind when I saw "rules". =)

:Den