100 lines, but you get a message reminding you to trim your posts if that’s
the reason you went over. I’m sure he also tracks them and will start
sending stinkbugs to anybody that flouts the rule too often. ;^)
I’ve been struggling with the topic for several weeks now: you’d be
surprised how little information there is out there on actually building
something like this. I looked at the papers by Yoder and Barclow (Patterns
for implementing application security) but on one hand they were slightly
over my head (requiring some knowledge of more general design patterns) and
on the other hand they just didn’t go deep enough (there were no object
models, no examples of combining the various patterns, etc – they just
covered the most basic of conceptualizations).
There’s one article at Macromedia.com that builds something like this but so
painfully simply it’s really not worth looking at if you really want to do
it (the article really covers general CFC creation in detail, but very
little about the security system).
I even paid for an article/sample code that (I think) Larry Lyons
recommended, but it was also a bit on the simplistic side (although
perfectly workable) and any caching or advanced features. It also (it
seemed to me) lacked a cohesive philosophy of security.
I tried several downloads from the Macromedia Exchange and just didn’t care
for them (again, mostly too simplistic and lacking in flexibility).
Most of the systems, for example, call the database then create some type of
“user” object then store that in the session scope. That’s fine, but
problems occur if an admin changes the person’s permissions (since they
won’t take effect until the next log in) or the user ends up with multiple
sessions. It just always seemed somehow “flimsy” to me (even tho’ I’ve done
it in the past myself).
I’ve been banging my head against a wall thinking: there must be something
I’m missing. Some “standard” design that I can steal, some basic object
model that I can start with. I just found nothing useful.
As for “what it does and why you need it” – well, I don’t know why you need
it; but I do know that I need it. And if I do (since I’m nothing special)
maybe some other people might as well. ;^)
The primary goal for me was to design a system that required very little
knowledge of the application it was protecting. The system I’ve described
(but remember I haven’t built it yet – so this is all conjecture) will work
just fine if the application doesn’t enabled the session scope (in fact if
you instantiate it in the server scope you don’t even need the application
scope).
The outside application defines the “touch points” and keys used to get at
the information. I’m actually quite pleased with that fact: it was an
important turning point for me not to consider how to get things “into the
session” and using the session as a cache point.
The system is complex, but caches its information very aggressively so (I
hope!) it should still be quite fast. The caching adds complexity but also
enables us to deal with multiple entities working on the same data very
gracefully. When I, as an admin, revoke or add permissions on your account
you’ll see the change on the very next request.
Once I get the damn thing done it should be a nice, clichéd “black box” –
you won’t have to know how it works inside to use it. As I said the system
itself won’t have any interface at all (although when/if I distribute it
I’ll include a sample interface) so it’ll be applicable to pretty much any
CF application.
Lastly, although I didn’t go into this in the first post (it was more than
long enough) but I’ve planned the system for expansion: all of the
persistence-layer stuff (database interaction) is completely segmented.
Adding support for a new database is as easy as creating a new set of
“broker” components with your database-specific code (although it doesn’t
have to be a database).
Since the brokers to use are determined at run-time you can use the same
codebase (as long as you have the brokers) to manage as many
datasources/data types as you like. You could have two applications use
Access, another use SQL Server and another use XML or LDAP. Although for my
part I’ll probably only be building SQL Server code (at least at first).
Can you tell I’m a little exciting my the idea?
In the final analysis I’m just building because I think it’ll help me and
I’m just publishing it for free to force me to wrote documentation for it
(and maybe get some help with it). There very little selflessness in the
process. ;^)
Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
