Re: [cgiapp] Sessions and Permissions
(sent to list -- Phil, if you want yours to the list, you might want to resend. Have I mentioned lately I hate lists that don't reply-To by default?) Is anyone's web server really that strapped for disk space? This kind of compression is great for operating systems and disk controllers but is generally inappropriate for things like web applications. Why say $prefs |= 32768 when you can say $prefs[15] = 1? Because databases don't store arrays? a string can be a real challenge, whereas in a normalized (1NF+) database it's trivial. OTOH, if you don't need the flexibility/scalability, you probably don't need to bother. As I said, putting the permissions into databases is more powerful, but sometimes the above is easier to maintain than a table of permissions, a table of users, a table of which users are in which groups, a table of what permissions each group has, etc. - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Sessions and Permissions
At 05:34 PM 04/02/2002, Benjamin wrote:
You hardcoded the modename in every runmode, but if you put the
check into cgiapp_init, then you could do something like this (of
course you could use the same code in every runmode, or write a
subroutine, like Greg suggested, but if the code is placed into
cgiapp_init, you have to maintain the permission checking code only
in one place ... don't forget TIMTOWTDI ;)
my $q = $self-query();
my $modename = $q-param('rm');
unless ($admin-checkPermission(ModuleName_$modename))
{
# They do not have permission so send them to the error
runmode
$q-param('rm', 'error_rm');
}
The reason I didn't use something like this is that I have multiple
run modes that map to the same permission setting. I have
permissions like Edit Event which covers run modes
event_edit_form, event_edit, event_cancel, etc.
--
Greg Marr
[EMAIL PROTECTED]
We thought you were dead.
I was, but I'm better now. - Sheridan, The Summoning
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Sessions and Permissions
At 11:36 AM 04/03/2002, Jesse Erlbaum wrote: Does this describe your situation? If so, why don't you simply break your application into multiple applications, by required authority? Each application could then have its own instance script. At this point, you've lost much of the power of CGI::App, because you have to divide your application into different parts based on what possible access groups you might have in the future. If you're moving from access group to access group within a single set of operations, you not only have to set which run mode you're calling, but which instance script handles that run mode. If you need to move a run mode into a different access group, you need to move the run mode into a different application, and then find all callers of that application and update them to call the new instance script. It gives you much more room to be flexible if your access control is based on a single statement at the top of each run mode that declares the access group for that run mode. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Sessions and Permissions
Hey Greg -- At 11:36 AM 04/03/2002, Jesse Erlbaum wrote: Does this describe your situation? If so, why don't you simply break your application into multiple applications, by required authority? Each application could then have its own instance script. At this point, you've lost much of the power of CGI::App, because you have to divide your application into different parts based on what possible access groups you might have in the future. I don't agree. Judiciously scoping application modules is one of the cornerstone concepts in CGI::Application. This concept is in opposition to Server-Page systems which homogenize every run-mode into a separate file, or monolithic Mega::Application modules which contain every run-mode in your site -- which is effectively the same thing as in a Server-Page system. CGI-App is based, in no small part, on the idea that an application is a collection of related run-modes. Related may be based on similar function, or similar required credentials. Properly scoping your application modules is part of the art of being a good CGI::Application developer. Scoping your app modules always involves asking yourself where one application module should end, and another one begin. This needs to be based on specific interface design. You can't do it from 20,000 feet. The decision needs to be based on how the modules are used, and by whom are they used. This is not to say you can't have a large body of code which is shared between modules! At VM we often have constituent helper modules which contain methods which are used by many -- often ALL -- CGI::Application modules on a site. (These types of modules are sometimes referred to as Model modules by M/V/C purists.) In our architecture, the CGI-App modules often are fairly small, relying on the helper modules to perform much of the heavy lifting and business logic. We're find of saying here, that life does not end at version 1.0. It is always necessary to re-factor applications to update them for unforeseen use. There have definitely been times when new functionality (a feature, or a new security delegation) has required us to move a run-mode from one application module to another. Through the proper use of modularization via helper modules, this task can be made to have a minimal cost. It is, in fact, the natural evolution of any software system. IMHO, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Sessions and Permissions
At 01:00 PM 04/03/2002, Jesse Erlbaum wrote: Hey Greg -- At 11:36 AM 04/03/2002, Jesse Erlbaum wrote: Does this describe your situation? If so, why don't you simply break your application into multiple applications, by required authority? Each application could then have its own instance script. At this point, you've lost much of the power of CGI::App, because you have to divide your application into different parts based on what possible access groups you might have in the future. I don't agree. Judiciously scoping application modules is one of the cornerstone concepts in CGI::Application. While that's true, I just don't see access groups as a good method to use for this scoping. The access control can often be totally unrelated to anything else in the application. CGI-App is based, in no small part, on the idea that an application is a collection of related run-modes. Related may be based on similar function, or similar required credentials. Properly scoping your application modules is part of the art of being a good CGI::Application developer. I prefer grouping based on function over grouping based on required credentials, especially when the required credentials part is more fluid, and it is simpler to change the credentials for a run mode than it is to move that run mode to a different application. Scoping your app modules always involves asking yourself where one application module should end, and another one begin. This needs to be based on specific interface design. You can't do it from 20,000 feet. The decision needs to be based on how the modules are used, and by whom are they used. However, when the by whom can change often, and the access groups have to be broken up and rearranged, you can either be helped by your access control logic, or hindered by it. I'd much rather change the access control in the mode than have to move the run mode to a different application and then have to change everything that refers to it. Moving run modes from app to app also makes it much more difficult to follow the revision control history of the application. We're find of saying here, that life does not end at version 1.0. It is always necessary to re-factor applications to update them for unforeseen use. Absolutely. I'm on version 5 (at least) of this system, which was originally written as a text-based command line application back in 1995. Since then, it's been rewritten as a combination text-based, Motif-based app, had a web interface added, and now totally redesigned and rewritten in CGI::Application/MySQL. There have definitely been times when new functionality (a feature, or a new security delegation) has required us to move a run-mode from one application module to another. Through the proper use of modularization via helper modules, this task can be made to have a minimal cost. It is, in fact, the natural evolution of any software system. That's true, and you can either design things so that it is easy to change the security delegation, (higher short-term cost, lower long-term cost) or you can design things so that it is easy to write the security groups now, and difficult to change them in the future (lower short-term cost, higher long-term cost). The one place where I've split the application based on access control is one portion of the application that will always be open to the public. In this case, I have one application/instance script that doesn't use authentication, and one that does. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Sessions and Permissions
Hey Kenny -- The only question is flexibility. If I wanted to change the delete_widget to allow a different group to have access to it how would I do that? Would I have to physically move the mode? Here are the details. I have users in different groups with different permissions. [...snip...] The company that will use this software wanted to be able to change thier minds. For example, I think techs should be able to edit and delete widgets but they don't need to view confidential stuff. Given these circumstance, I would create three separate CGI::Application application modules: 1. Widget Viewer 2. Widget Editor 3. Confidential Stuff Viewer This is based on a combination of object (widget, confidential stuff) and function/access (Viewer/Tech, Editor/Manager-only). See how this plays itself out if you add the functions: edit_configential_stuff_form update_configential_stuff delete_configential_stuff If Managers are allowed to edit confidential stuff as well as view it, you *may* put all these functions into the existing Confidential Stuff Viewer application module. However(!), if you suspect that at some time in the future it may be beneficial to change who has access to the edit_configential_stuff, smart money would be to put these three new functions into a separate application module. Consider: Would you *ever* grant someone access to the update_configential_stuff run-mode, but *NOT* to the edit_configential_stuff_form? How do they update without a form? Only in the abstract does this even remotely make sense. These two functions are clearly part of the same application. OTOH: Would you ever grant someone access to view_confidential_stuff, but not edit_configential_stuff_form? Probably! This is a good yardstick to use do determine the need to make separate applications. Once these applications are separated in a logical fashion, access can be granted to them intuitively. If you change your mind and want to give Tech users access to the Confidential Stuff Viewer you can move the viewer into a directory Tech users can access, or you can change the permissions governing the directory in which the Confidential Stuff Viewer is located. If John is promoted, and Doug is hired as the new tech, move John into the Manager group, and assign Doug to the Tech group. It's that simple. Although well beyond the scope of CGI::Application, once you get into writing your authentication and authorization rules, you can do things even more complex than working only at the directory level. There is no reason you couldn't deal with individual files instead of directories, for instance. (There may be good reasons, from an ease-of-management point of view, to deal with directories -- but you don't *have* to.) This is a separate topic, however, and one more appropriate to a discussion about mod_perl (or whatever web server API you're using). TTYL, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Sessions and Permissions
On Wed, 3 Apr 2002, Jesse Erlbaum wrote: I don't agree. Judiciously scoping application modules is one of the cornerstone concepts in CGI::Application. I originally tried to design Cascade ( http://summersault.com/software/cascade/ ) by grouping functionaly according to the needed authentication level. This fell apart quickly though, because many run modes needed to be run by different kinds of users. I ended up redesigning the structure more around functionality and that worked better for me. I did try something like Jesse suggests of having different instance scripts for admins and public users, which perhaps might access the same code, but with different authentication requirements. That didn't work out well either for me because I had a lot of links to other run modes, and if I linked from admin.cgi to something accessed through public.cgi, which didn't authenticate me, then the administrative specific features went away. In the end, I ran everything through a single instance script, while trying to break up the modules used by functionality, ideally only loading the ones I needed as needed. The setup routine looked up the autentication needed for the run mode requested in a config file, and redirects the user for registeration if they need to be logged or need additional permissions to view the run mode. This at least keeps authentication related code out of the run modes. If it all sounds a bit messy, it is. Jesse's idea of handling authentication at a level beneath (above?) the application is appealing and is something I would likely try if I was operating in a mod_perl environment. As Cascade grows, I'm thinking about breaking it out into multiple instance scripts again, but I haven't gotten around to architecting exactly how that would work. -mark http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Sessions and Permissions
However, when the by whom can change often, and the access groups have to be broken up and rearranged, you can either be helped by your access control logic, or hindered by it. I'd much rather change the access control in the mode than have to move the run mode to a different application and then have to change everything that refers to it. Moving run modes from app to app also makes it much more difficult to follow the revision control history of the application. I am encouraged, by the spirited discussion, that my question was not a stupid one. I am controlling authorization/sessions mostly via a SQL database with logic built into the app to check the users permission via a relationship query. I needed a way for each renamed to tell me who it was for that part of the query. I am grouping each module by function. I am also doing all of the authorization/session handling via a separate module. To change permission I update the SQL Database to reflect a new relationship between the user and a role and the role and a renamed. I think there are several valid solutions to this problem. I have used Apache::Session with CGI::App on some of the other apps I have developed. I will probably incorporate Benjamin's suggestion on the dynamic permissions check in cgiapp_init to stop incorrect entry in each mode. I am only a purist in two things: 1.) Is has to work according to the spec. and 2) They have to pay me for it. Thanks, Kenny Pyatt President Design Shack www.dshack.com - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Sessions and Permissions
I guess spell check though it would be better to call run-modes renamed :-) Kenny Pyatt wrote: However, when the by whom can change often, and the access groups have to be broken up and rearranged, you can either be helped by your access control logic, or hindered by it. I'd much rather change the access control in the mode than have to move the run mode to a different application and then have to change everything that refers to it. Moving run modes from app to app also makes it much more difficult to follow the revision control history of the application. I am encouraged, by the spirited discussion, that my question was not a stupid one. I am controlling authorization/sessions mostly via a SQL database with logic built into the app to check the users permission via a relationship query. I needed a way for each renamed to tell me who it was for that part of the query. I am grouping each module by function. I am also doing all of the authorization/session handling via a separate module. To change permission I update the SQL Database to reflect a new relationship between the user and a role and the role and a renamed. I think there are several valid solutions to this problem. I have used Apache::Session with CGI::App on some of the other apps I have developed. I will probably incorporate Benjamin's suggestion on the dynamic permissions check in cgiapp_init to stop incorrect entry in each mode. I am only a purist in two things: 1.) Is has to work according to the spec. and 2) They have to pay me for it. Thanks, Kenny Pyatt President Design Shack www.dshack.com - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Kenny Pyatt President Design Shack www.dshack.com - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Sessions and Permissions
At 02:21 PM 04/03/2002, Kenny Pyatt wrote: However, when the by whom can change often, and the access groups have to be broken up and rearranged, you can either be helped by your access control logic, or hindered by it. I'd much rather change the access control in the mode than have to move the run mode to a different application and then have to change everything that refers to it. Moving run modes from app to app also makes it much more difficult to follow the revision control history of the application. I am encouraged, by the spirited discussion, that my question was not a stupid one. No, it's definitely not a stupid one. I am only a purist in two things: 1.) Is has to work according to the spec. and 2) They have to pay me for it. I get paid for writing other things. I'm not paid for the things I do using CGI::Application, so I do whatever makes things easiest for me. This includes still providing the required functionality, of course, since if I don't do that, I get to go back and do it again. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Sessions and Permissions
Greg,
You rule. I had not thought of adding the permissions error message
to the Admin module until you
gave me the idea. I rewrote my check permissions module to handle it
by redirecting to an error template and I only have to add one line of
code for each mode. Thank you very much. You just saved me 2000 lines
of code .
Greg Marr wrote:
At 02:17 PM 04/02/2002, Kenny Pyatt wrote:
The decision has been made (although I can change it) to use a
user-type/run-mode permission scheme. I created a database that
handles which users are which type and which types have access to
which mode. I even have it working :-)
This sounds like exactly what I've done. I like this style, because
then the run modes are responsible for determining what kind of access
they need, and I don't have to maintain a separate list. I can also
just look at each run mode and see that it has the proper access,
rather than having to refer back to some master list somewhere.
The modes are given unique ids that are hard coded in. Each run-mode
looks like this:
sub Mode
{
my $self = shift;
my $admin = $self-param('admin');
# Check for permission.
if ($admin-checkPermission('ModuleName_Mode '))
{
# The have permission so go ahead
}
else
{
# They do not have permission so tell them.
}
Mine's a little simpler though:
sub Mode
{
my $self = shift;
$self-CheckAccess('Mode');
# If execution gets to this point, they have permission
[...]
and then CheckAccess looks like this:
sub CheckAccess($)
{
my ($self, $module) = @_;
# Not providing a module is always fatal
defined($module) or die CheckAccess: module not defined;
# Perform the authentication stuff here
# If access was granted, return.
return(1) if $access_was_granted;
# Access denied, report the error to the user, and die.
warn Refusing access to $module for $username\n;
die You do not have permission to perform this operation.\n;
}
--
Thanks,
Kenny Pyatt
President
Design Shack
www.dshack.com
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
