I'm going to toss in a dime here. I see the convergence of two threads here;
security and code resue. I stated yesterday that almost nobody truly ever
reuses code. But here lies a situation where we could both reuse code, and
make a really good universal security model.
I personally believe in the 'users > roles > permissions' secuity, as it
works so well with MS SQL. The question was asked 'what IS a permission?'
I'd say this:
tbdUsers
fldID (int PK)
fldUsername (varchar)
tbdPermissions
fldID (int PK)
fldPermission (varchar)
tbdRoles
fldID (int PK)
fldRole (varchar)
fldPermissionID (int FK tbdPermissions.fldID)
tbdUserRoleAssignments
fldID (int PK)
fldUserID (int FK tbdUsers.fldID)
fldRoleID (int FK tbdUsers.fldID)
[NOTE - This is very simplistic! Of course you would expand on it]
Something like this... You make a security app that has a users > roles >
permissions security model built into it. You go in and, either manually via
SQL or via web interface, populate the permissions and roles.
Then for any situation where you want to apply a permissions standard you
query the db to see if a record exists in tbdUserRoleAssignments. If it
does, then they have it. IF not, they don't.
The core of the security model is: If you query the db, and find 0 records
for a particular user/role in tbdUserRoleAssignments, then you set a
"permissionGranted" flag to false, else set it to true. What the developer
does with this knowledge is up to them to code in their app.
The entire security component would be a circuit you could drop into any FB3
app. Since it is data-driven, once the code is bug-free, you could indeed
'burn' it to ROM and forget about it. This one app circuit alone could
revolutionize the acceptance of FB3, since you'd have a solid security model
that anybody could toss in.
Anybody want to dare to work on such a thing? It would benefit the community
as a whole.
> -----Original Message-----
> From: Tim Heald [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 6:37 PM
> To: [EMAIL PROTECTED]
> Subject: RE: secure tag and permissions
>
> Hal,
> Complexity, for complexities sake does not mean it is robust, nor
> does it
> mean it is better. Simplify, break it down and make it easy. Isn't that
> part of what Fusebox is teaching us? If I were building a machine, I
> would
> want as few moving pieces as possible, just very well made pieces. When
> you
> define a group you define it in such a way that it is symbolic of one
> specific role/ability sort of like you would design (sure to stir
> something
> up here) a fuse? A single group for a single action. Also this makes it
> much easier to relate to the physical world. I know what an article
> reader
> is.
>
> I mean sure, I am not as advanced as you and Lee, and maybe that's
> why I
> don't get the whole bit scheme. I will stick with something that has
> worked
> for me, and works well.
>
> Tim Heald
> ACP/CCFD
> Application Development
> www.schoollink.net
>
> -----Original Message-----
> From: BORKMAN Lee [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 6:39 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: secure tag and permissions
>
>
> Mate, now you are impugning my manhood! Not robust indeed!
>
> HAVE AT YOU!!!
>
> -----Original Message-----
> From: hal helms [mailto:[EMAIL PROTECTED]]
>
> I see your point, but simply don't find your model robust enough.
> Apparently, you find it works fine. I'm happy to leave it there.
>
> -----Original Message-----
> From: Lee Borkman [mailto:[EMAIL PROTECTED]]
>
> Now you are confusing UserGroups (independent of applications) with
> Roles (dependent on Applications). For shame!
>
>
> IMPORTANT NOTICE:
> This e-mail and any attachment to it is intended only to be read or used
> by
> the named addressee. It is confidential and may contain legally
> privileged
> information. No confidentiality or privilege is waived or lost by any
> mistaken transmission to you. If you receive this e-mail in error, please
> immediately delete it from your system and notify the sender. You must
> not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient. The RTA is not responsible for any unauthorised alterations to
> this e-mail or attachment to it.
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
