Late last year, I started to notice that many of the web apps I was designing
and working on were based and easier to write and think about when the design was
structured around the client's web browser events. In other words, every click in the web app
could be defined as a specific event of the overall app.
Based on that design model, here are some of the ideas I had for a authorization/membership layer:
The main module acts as a "mediator" or "listener" for all application events.
In addition, it provides a nice, fairly portable interface for web events to talk to other modules.
The basic model of the system follows:
The finest granularity of the system is an event.
Events can be grouped into modules.
Modules can be grouped into services/apps.
Users and Groups can be assigned events, modules and/or services/apps.
When building an application you define modules based on events.
And again modules are based on events.
Each event is stored in the database.
Each event has an Event-Id.
Also each module is stored in the database.
Each module has an Module-Id.
Each module can have 1 or many events.
The same is for services/apps...in database...serviceId/apps/Id
When you log into system for the first time during a session, an event token is calculated for you
based on the events, modules and services you and your groups belong to.
From that point on during the application session, every event is tested against
your token (could be stored in a cookie or variable).
That should give you some idea of where the model was going.
Is this to complicated of an approach?
What are your thoughts?
I wonder if anyone has wriiten anything like this already? When I looked around back in
March I didn't find much of a complete solution or really anything.
Harold Gilchrist
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like Harold's idea of mapping this to event/module/service. (I am more familiar to event/transaction model for realtime systems, but this is similar)
Events are something that the user does, or maybe timeouts.
I don't like the idea to store events in the databse, though. Only thing you need to store is event - service mapping. Putting events to database, would be okay if we want to log all the actions that users did, or maybe if we want them to backtrack (undo) their changes, but otherwise, I don't see any merit for storing them. (or maybe I just didn't understand what you meant to say).
Having said that, I also think user authentication might be too small an application to use these concepts. BTW what I would really like phortify to do is develop a framework for user authentication and keep everything that is not needed for authentication outside of it as user-writable functions. (things like user permissions etc). All userauth needs is 2 kinds of users - general users and superuser (which can modify others) but this can be achived just by userid's without going for additional permissions .
Just my 2 paise.
Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Late last year, I started to notice that many of the web apps I was designing
and working on were based and easier to write and think about when the design was
structured around the client's web browser events. In other words, every click in the web app
could be defined as a specific event of the overall app.
Based on that design model, here are some of the ideas I had for a authorization/membership layer:
The main module acts as a "mediator" or "listener" for all application events.
In addition, it provides a nice, fairly portable interface for web events to talk to other modules.
The basic model of the system follows:
The finest granularity of the system is an event.
Events can be grouped into modules.
Modules can be grouped into services/apps.
Users and Groups can be assigned events, modules and/or services/apps.
When building an application you define modules based on events.
And again modules are based on events.
Each event is stored in the database.
Each event has an Event-Id.
Also each module is stored in the database.
Each module has an Module-Id.
Each module can have 1 or many events.
The same is for services/apps...in database...serviceId/apps/Id
When you log into system for the first time during a session, an event token is calculated for you
based on the events, modules and services you and your groups belong to.
From that point on during the application session, every event is tested against
your token (could be stored in a cookie or variable).
That should give you some idea of where the model was going.
Is this to complicated of an approach?
What are your thoughts?
I wonder if anyone has wriiten anything like this already? When I looked around back in
March I didn't find much of a complete solution or really anything.
Harold Gilchrist
Harold,
This sounds like a nice design... do you have more detail, perhaps formal ? with diagrams ?
> The finest granularity of the system is an event.
> Events can be grouped into modules.
> Modules can be grouped into services/apps.
Can you detail events, give example modules, services, apps ?
If you can communicate the idea to me, perhaps i can write it up properly, even use it as the base model for the project.
Have a quick look at http://php.teklan.com.au/ , and see if it has some similarities to your approach.
Thanks,
Rob
I like Harold's idea of mapping this to event/module/service. (I am more familiar to event/transaction model for realtime systems, but this is similar)
Events are something that the user does, or maybe timeouts.
I don't like the idea to store events in the databse, though. Only thing you need to store is event - service mapping. Putting events to database, would be okay if we want to log all the actions that users did, or maybe if we want them to backtrack (undo) their changes, but otherwise, I don't see any merit for storing them. (or maybe I just didn't understand what you meant to say).
Having said that, I also think user authentication might be too small an application to use these concepts. BTW what I would really like phortify to do is develop a framework for user authentication and keep everything that is not needed for authentication outside of it as user-writable functions. (things like user permissions etc). All userauth needs is 2 kinds of users - general users and superuser (which can modify others) but this can be achived just by userid's without going for additional permissions .
Just my 2 paise.
Amit