Re: [cgiapp] User authentication
Hi Drew,
I have been hinting at an Authentication plugin for a while now, but
haven't finished it yet. I did a little bit more work on it
yesterday, but I don't have any docs, or any tests written for the
module yet.
I you also have a start on a module, maybe we can colaborate. From
your comments below it sounds like we are probably on the same
track...
I was planning to use the CAP::Session module in combination with
CGI::Session::Auth which is an addition on top of CGI::Session that
handles authentication. That is what I use in my apps right now, and
I am just trying to abstract the code out into a plugin.
Here is an example of how I see it working:
package My::CGIAPP;
use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Auth;
use base qw(CGI::Application);
sub setup {
my $self = shift;
$self-start_mode('default');
$self-mode_param('rm');
$self-run_modes([ qw(
default
other_runmode
) ]);
$self-require_authentication(1);
$self-require_authorization('agroup');
}
The call to 'require_authentication' makes sure that the user must be
logged in to access the runmodes in this module. The call to
'require_authorization' makes sure that the user belongs to the group
'agroup'.
So basically you have authentication and authorization on a per module
basis (it could probably be extended to do per runmode auth, but I
haven't needed that, and think it is probably a design/organizational
mistake to do so anyway).
The implementation is fairly simple in that a callback is registered
at the 'prerun' level that calls $self-auth-authenticate() which
tells CGI::Session::Auth to check to see if the user is logged in, or
trying to log in by looking at the CGI params.
If the user is not logged in (and we require authorization in the
runmode) then the user is redirected to a login page.
If the user is logged in, but doesn't belong to the right group, then
they are redirected to a forbidden page.
If at anytime the user loads a runmode called 'logout', then the user
is logged out.
I am trying to find a way to have this module work in a way that
doesn't require any configuration at all (like the session object),
but it is a bit more difficult, since it depends on custom runmodes
(login and forbidden). And also it would require the login fields to
be named correctly.
The only way that I can think to do it is to have the plugin add some
new runmodes to the module! Does anyone have any suggestions on how
to do that cleanly? Is it even wise?
Anyway, Drew, if you (or anyone else for that matter) is willing to
colaborate on an Auth module, I would be happy to help out.
Cheers,
Cees
On Fri, 29 Oct 2004 01:28:42 -0400, Drew Taylor
[EMAIL PROTECTED] wrote:
I was playing around with Maypole yesterday as a possible alternative
or addition to CGI::App. There are many excellent features: integrated
support for user authentication, automatic form generation, CRUD
capabilities, etc. For the moment, I've decided that Maypole is not
for me. But I'd like to be able to bring drop-in support for simple
user authentication into a C::A application.
I'm planning on using Cees' C::A::Callbacks (nice job!!) to handle
adding the appropriate code checks. Anyone have ideas (or code) on
ways to do it in a generic way? I'm thinking of doing it ala Maypole
since that should be relatively easy to implement and seems easy to
specialize in a particular application.
The way maypole handles user authentication is through the
authentication() method. This simply returns a true or false value.
The default implementation allows all requests. Applications can
define their own ideas for authentication. One authentication module
which takes authentication to the next level is
Maypole::Plugin::Authentication::Abstract. It defines three levels of
authentication (using the session as a stash)
1. Public: No authentication, only session management
2. Private: Authenticate once, go everywhere
3. Restricted: Authenticate and reauthorize with a ticket for every
request (best used in a post form as hidden input)
My current plan is to combine the use of C::A::Plugin::Session to do
session management, and add some glue/stub methods for the actual
authentication. Restricted is overkill for me ATM and will probably
not be implemented initially. I'm thinking of calling it
CGI::Application::Plugin::Authentication. All ideas (and criticism)
welcomed.
Drew
--
Drew Taylor * Web development consulting
Email: [EMAIL PROTECTED] * Site implementation hosting
Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To
Re: [cgiapp] Re: order of method calls
On Thu, 28 Oct 2004 20:14:58 -0400, Clayton Scott wrote: Hi Clayton Can you not adjust the font size in your web browser? The default My apologies. I had thought about that, but I did not actually check the current setting. I should have - it was on 'Smallest'. -- Cheers Ron Savage, [EMAIL PROTECTED] on 29/10/2004 http://savage.net.au/index.html - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] User authentication
Drew and Cees,
I am in the process of converting over a non CGA application to run under
CGA. (Sort of) does the same stuff as CGA in a non-OO way. My application
has implemented user and group authentication and this is what I try to
accomplish from a design perspective.
Run mode level authentication is preferable otherwise in your example it
looks like you would need separate your non-authenticated run modes out into
another CGA module (+ instance scripts etc) even though they are just a
different view on of same application model. If you get rm-level security
right you get application security for free!
A point I would like to add is that the documentation on the wiki strongly
suggests doing authentication using the app server and not in your
application. This (I think) would not provide the necessary granularity for
run-mode level security and also using a consumer(ish) ISP they do not allow
me access to httpd.conf to install my own modules etc.
Crud checking at the entity being viewed/updated/ for the user since this
allows you to re-use the rm code and html template code. E.g. a user can
change their own address details but not others, even though they may be
able to see them. Think of a user directory kind of thing.
In order for users to discover more of the site and encourage them to
register and sign in then I allow them see links/menu items that when they
click on, it trips a sign in and then once signed in it redirects them to
where they wanted to go through saving path info etc. in a session
attribute. I have implemented this in a MyApp:CGIAPP class that provides a
standard login-rm that gets triggered if authentiation is required. I'm not
sure you need to cover this but I find it is very helpful to open sites.
I do often wonder whether I should do all my authentication using some sort
of generic directory service rather than mucking about with my own user
tables, group tables and so forth. Another plugin for your plugin to
support directories?
O.
-Original Message-
From: Cees Hek [mailto:[EMAIL PROTECTED]
Sent: 29 October 2004 07:32
To: Drew Taylor
Cc: CGIApp
Subject: Re: [cgiapp] User authentication
Hi Drew,
I have been hinting at an Authentication plugin for a while now, but haven't
finished it yet. I did a little bit more work on it yesterday, but I don't
have any docs, or any tests written for the module yet.
I you also have a start on a module, maybe we can colaborate. From your
comments below it sounds like we are probably on the same track...
I was planning to use the CAP::Session module in combination with
CGI::Session::Auth which is an addition on top of CGI::Session that handles
authentication. That is what I use in my apps right now, and I am just
trying to abstract the code out into a plugin.
Here is an example of how I see it working:
package My::CGIAPP;
use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Auth;
use base qw(CGI::Application);
sub setup {
my $self = shift;
$self-start_mode('default');
$self-mode_param('rm');
$self-run_modes([ qw(
default
other_runmode
) ]);
$self-require_authentication(1);
$self-require_authorization('agroup');
}
The call to 'require_authentication' makes sure that the user must be logged
in to access the runmodes in this module. The call to
'require_authorization' makes sure that the user belongs to the group
'agroup'.
So basically you have authentication and authorization on a per module basis
(it could probably be extended to do per runmode auth, but I haven't needed
that, and think it is probably a design/organizational mistake to do so
anyway).
The implementation is fairly simple in that a callback is registered at the
'prerun' level that calls $self-auth-authenticate() which tells
CGI::Session::Auth to check to see if the user is logged in, or trying to
log in by looking at the CGI params.
If the user is not logged in (and we require authorization in the
runmode) then the user is redirected to a login page.
If the user is logged in, but doesn't belong to the right group, then they
are redirected to a forbidden page.
If at anytime the user loads a runmode called 'logout', then the user is
logged out.
I am trying to find a way to have this module work in a way that doesn't
require any configuration at all (like the session object), but it is a bit
more difficult, since it depends on custom runmodes (login and forbidden).
And also it would require the login fields to be named correctly.
The only way that I can think to do it is to have the plugin add some new
runmodes to the module! Does anyone have any suggestions on how to do that
cleanly? Is it even wise?
Anyway, Drew, if you (or anyone else for that matter) is willing to
colaborate on an Auth module, I would be happy to help out.
Cheers,
Cees
On Fri, 29 Oct 2004 01:28:42 -0400, Drew Taylor [EMAIL PROTECTED]
wrote:
I was playing around with Maypole yesterday as a possible
[cgiapp] User Auth Plugin Question
I was searching through the list archives and I cannot find a mention (besides this guy[1] asking and not getting a response (to the plugin question)) of why we should change our code from C:A:ValidateRM to C:A:P:ValidateRM. I've heard lazy loading thrown around, but I'm not sure what that means. Intuitively (to me), it means that we can use the plugin module, but it's not loaded until it's actually being used in the particular runmode, saving memory. That right? Also, when it comes to user authentication, when I dabbled in that, I came across Apache::AuthCookie[2], which in my opinion is a GREAT way to handle user auth. It separates the whole authentication code away from your application code and you can easily protect your application within Apache's configuration for your application's location. Cheers, Jason [1]: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02200.html [2]: http://search.cpan.org/~mschout/Apache-AuthCookie-3.04/AuthCookie.pm - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: feedback on ::Plugin::ConfigAuto update (a use for register_hook?)
Once these features are moved into CGI::App, I see the documentation appearing a little out of the way in a section on WRITING PLUGINS or Advanced Usage. There is no need for new users to be trying to figure out if they need these features, in my opinion. The whole WRITING PLUGINS sections could be moved into a separate POD altogether... perldoc CGI::Application::Callbacks would bring it up. I think having a development version available for several weeks would be useful for folks to test with existing applications. It seems that we can already use Cees' module for that. It works as a drop-in replacement for CGI::App and all you have to change is the name of the module in your use base line. (Or Cees could rewrite C::A::Callbacks to work as a plugin, exporting all its methods ) Thilo - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] AutoRunmode plugin updated to use callbacks
Hi,
It is unfortunate that it needs to be implemented using the prerun
hook, but I can see your reasons for not rewriting the 'run' method in
CGI::Application.
This module also shows a very good example of the potential usefulness
of the callbacks patch as well.
I updated the AutoRunmode plugin to use the callback interface
(optionally, the Exporter interface still works, as does explicitly
calling the method)
http://perl-pad.sourceforge.net/cgiapp/AutoRunmode.html
http://perl-pad.sourceforge.net/cgiapp/CGI-Application-Plugin-
AutoRunmode-0.02.tar.gz
So now you can do this:
package MyApp;
use base 'CGI::Application::Callbacks';
use CGI::Application::Plugin::AutoRunmode ();
sub setup{
my $self = shift;
install CGI::Application::Plugin::AutoRunmode($self);
}
sub do_something : Runmode{
#
}
At the moment, the callback interface is a little verbose, you have to
first use the module, and then install the callbacks.
Maybe if callbacks and plugins become popular, we could come up with
something more concise, for example
sub setup{
my $self = shift;
$self-use_plugin('::AutoRunmode');
}
where use_plugin() would use the plugin and call some install method
to let it set itself up.
Thilo
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
Owain wrote: Drew and Cees, I am in the process of converting over a non CGA application to run under CGA. (Sort of) does the same stuff as CGA in a non-OO way. My application has implemented user and group authentication and this is what I try to accomplish from a design perspective. Run mode level authentication is preferable otherwise in your example it looks like you would need separate your non-authenticated run modes out into another CGA module (+ instance scripts etc) even though they are just a different view on of same application model. If you get rm-level security right you get application security for free! I originally thought rm-level auth was a bad idea since you should group the run modes into an application module that is used by the same type of user. I can however see why you might want to group several run modes that deal with the same data type together... but I'm still not totally convinced. Anyone else have any thoughts on this? I just always do module level auth and then never have to worry about securing individual run modes, just the app module. A point I would like to add is that the documentation on the wiki strongly suggests doing authentication using the app server and not in your application. This (I think) would not provide the necessary granularity for run-mode level security and also using a consumer(ish) ISP they do not allow me access to httpd.conf to install my own modules etc. Now, this is where I definitely disagree. It's so easy for me to use mod_perl authentication (especially using C::A::P::Dispatch). You can be as granular or as top-level as you want. I just don't understand the ISP argument since root level servers are just $30 a month. That's serveral dozen low traffic domains. Or one or two mid level. If you don't want to deal with complete machine control, you can have virtual servers starting at $15 a month. With prices like that I just don't understand why more people don't just use the power of mod_perl. Crud checking at the entity being viewed/updated/ for the user since this allows you to re-use the rm code and html template code. E.g. a user can change their own address details but not others, even though they may be able to see them. Think of a user directory kind of thing. Going back the question above about rm-level auth. If you abstract your CRUD functions to your DAO (Class::DBI, etc) then having you can still reuse the majority of the code and templates. In order for users to discover more of the site and encourage them to register and sign in then I allow them see links/menu items that when they click on, it trips a sign in and then once signed in it redirects them to where they wanted to go through saving path info etc. in a session attribute. I have implemented this in a MyApp:CGIAPP class that provides a standard login-rm that gets triggered if authentiation is required. I'm not sure you need to cover this but I find it is very helpful to open sites. This can still be done even if the authenticated portions are in another app module. The auth we still redirect them to the sign up page. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User Auth Plugin Question
Jason Purdy wrote: I was searching through the list archives and I cannot find a mention (besides this guy[1] asking and not getting a response (to the plugin question)) of why we should change our code from C:A:ValidateRM to C:A:P:ValidateRM. I've heard lazy loading thrown around, but I'm not sure what that means. Intuitively (to me), it means that we can use the plugin module, but it's not loaded until it's actually being used in the particular runmode, saving memory. That right? Sort of, but not exactly. It doesn't lazily load the module, but rather the object being used. This means that in the case of the CAP::Session, it doesn't wait to load the CAP::Session module until it's used, but rather the underlying CGI::Session module isn't created until used. This does save some memory, but more than that, it says execution time in case the session is not actually used. Also, when it comes to user authentication, when I dabbled in that, I came across Apache::AuthCookie[2], which in my opinion is a GREAT way to handle user auth. It separates the whole authentication code away from your application code and you can easily protect your application within Apache's configuration for your application's location. I agree. I do like AuthCookie, but I've had more success rolling 20 line auth modules on my own. It really is quite easy to do. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
Michael, I originally thought rm-level auth was a bad idea since you should group the run modes into an application module that is used by the same type of user. I can however see why you might want to group several run modes that deal with the same data type together... but I'm still not totally convinced. Anyone else have any thoughts on this? I just always do module level auth and then never have to worry about securing individual run modes, just the app module. I've running a rather large multi-module system all based on C::A. My admin user interface allows me to create a permissions file to allow access to entire modules as well as individual aspects of that module. i.e. Reporting Module [ y / n ] - See General Reports [ y / n ] - Download As Excel [ y / n ] - See Detailed Reports[ y / n ] - View Geo-plot Report [ y / n ] For various reasons, some of these run-modes may not be accessible to the client (or certain admin users within the client's organization). Therefore, rm-level auth is nessecary for me, otherwise I'd have to split each of the rm's off into their own module and I'd have more modules then I know what to do with (which is currently almost the case anyways :p ) --- Steve Comrie - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
Steve Comrie wrote: I originally thought rm-level auth was a bad idea since you should group the run modes into an application module that is used by the same type of user. I can however see why you might want to group several run modes that deal with the same data type together... but I'm still not totally convinced. Anyone else have any thoughts on this? I just always do module level auth and then never have to worry about securing individual run modes, just the app module. I've running a rather large multi-module system all based on C::A. My admin user interface allows me to create a permissions file to allow access to entire modules as well as individual aspects of that module. i.e. Reporting Module [ y / n ] - See General Reports [ y / n ] - Download As Excel [ y / n ] - See Detailed Reports[ y / n ] - View Geo-plot Report [ y / n ] For various reasons, some of these run-modes may not be accessible to the client (or certain admin users within the client's organization). Therefore, rm-level auth is nessecary for me, otherwise I'd have to split each of the rm's off into their own module and I'd have more modules then I know what to do with (which is currently almost the case anyways :p ) While recognizing that tmtowtdi, this is how I deal with situations like the above... Using CGI::Application::Dispatch I would have a urls like these /app/reports/general /app/reports/download /app/reports/detail /app/reports/geo_plot So even if they were all in the same module, my auth handler could still provide such granularity. Location /app/reports/general Require group reports_general /Location Or something like that. You would define what the 'group reports_general' is in you auth handler. Just a different way to look at it, while still abstracting auth out of the application. I guess one of the main reasons I like to put my auth outside of the application is that I can protect non-cgiapp parts of the site (html, pdfs, graphics, etc) with the same auth structure. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] AutoRunmode plugin updated to use callbacks
Thilo Planz wrote:
At the moment, the callback interface is a little verbose, you have to
first use the module, and then install the callbacks.
Maybe if callbacks and plugins become popular, we could come up with
something more concise, for example
sub setup{
my $self = shift;
$self-use_plugin('::AutoRunmode');
}
where use_plugin() would use the plugin and call some install method
to let it set itself up.
I like the idea of making it less verbose. I haven't actually looked at
the callback implementation, but is it not possible to have the used
plugin just install itself? Why can't
use CGI::Application::Plugin::AutoRunmode;
just do the right thing and install all of the hooks, callbacks, etc
that it needs to do? This would be really non-verbose.
--
Michael Peters
Developer
Plus Three, LP
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
While recognizing that tmtowtdi, this is how I deal with situations like the above... Using CGI::Application::Dispatch I would have a urls like these /app/reports/general /app/reports/download /app/reports/detail /app/reports/geo_plot So even if they were all in the same module, my auth handler could still provide such granularity. Location /app/reports/general Require group reports_general /Location Or something like that. You would define what the 'group reports_general' is in you auth handler. Just a different way to look at it, while still abstracting auth out of the application. I guess one of the main reasons I like to put my auth outside of the application is that I can protect non-cgiapp parts of the site (html, pdfs, graphics, etc) with the same auth structure. The method that I use is to store each individual admins' permissions in a simple xml file permissions grantreporting.module/grant grantreporting.module.general/grant grantreporting.module.excel/grant denysome.normally.accessible.system.module/deny /permissions Then I've got one important function in my C:A base class, and one in my H:T base class. The C:A function will take a string like 'reporting.module' or 'reporting.module.excel' and test to see if the user has that grant in their permissions.xml file. The H:T base class function takes a users permissions.xml file and adds it to the template params before outputting so that inside each .tmpl file I can include things like: tmpl_if name='grant.reporting.module.excel' Show Excel Download Link /tmpl_if just so that I can hide the things that the user doesn't have permission to access. No need to show them what they can't touch. However, I don't have the same requirements that you do (at least not on that side of my app) to protect other web files based on user access, if I did, I might end up incorporating part of your solution into mine :-) --- Steve Comrie - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
On Fri, 29 Oct 2004 16:31:40 +1000, Cees Hek [EMAIL PROTECTED] wrote:
Hi Drew,
I have been hinting at an Authentication plugin for a while now, but
haven't finished it yet. I did a little bit more work on it
yesterday, but I don't have any docs, or any tests written for the
module yet.
You're ahead of me then! I'm still in the planning stages. The initial
code will probably happen this weekend.
I you also have a start on a module, maybe we can colaborate. From
your comments below it sounds like we are probably on the same
track...
That would be great. Two minds are better than one!
I was planning to use the CAP::Session module in combination with
CGI::Session::Auth which is an addition on top of CGI::Session that
handles authentication. That is what I use in my apps right now, and
I am just trying to abstract the code out into a plugin.
Here is an example of how I see it working:
package My::CGIAPP;
use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Auth;
use base qw(CGI::Application);
sub setup {
my $self = shift;
$self-start_mode('default');
$self-mode_param('rm');
$self-run_modes([ qw(
default
other_runmode
) ]);
$self-require_authentication(1);
$self-require_authorization('agroup');
}
The call to 'require_authentication' makes sure that the user must be
logged in to access the runmodes in this module. The call to
'require_authorization' makes sure that the user belongs to the group
'agroup'.
Nice. At $dayjob I have my own version of require_authentication(),
but I haven't (yet) needed group authentication. I've thought of using
Role-based authorization rather than groups because of the added
flexibility. IMHO it makes it easier to mix-n-match various
permissions with out going into group hell. But I admit to bias
because that is how a previous employer did it and it allowed
tremendous flexibility.
So basically you have authentication and authorization on a per module
basis (it could probably be extended to do per runmode auth, but I
haven't needed that, and think it is probably a design/organizational
mistake to do so anyway).
I have to go with Owain and disagree with you on this one. His example
was a perfect one: a user can edit their own profile (or list of
classes, etc), but they definitely can't modify someone else's, or
maybe even view it. Also, if you are doing role based authentication
you'll need the ability to disallow access to some functionality but
allow others.
The implementation is fairly simple in that a callback is registered
at the 'prerun' level that calls $self-auth-authenticate() which
tells CGI::Session::Auth to check to see if the user is logged in, or
trying to log in by looking at the CGI params.
That's how I was going to do it. Perhaps the login parameter names
could be configurable via arguments to MyApp-new()? I think it's
probably ok to hard code the names for the moment.
If the user is not logged in (and we require authorization in the
runmode) then the user is redirected to a login page.
If the user is logged in, but doesn't belong to the right group, then
they are redirected to a forbidden page.
If at anytime the user loads a runmode called 'logout', then the user
is logged out.
I am trying to find a way to have this module work in a way that
doesn't require any configuration at all (like the session object),
but it is a bit more difficult, since it depends on custom runmodes
(login and forbidden). And also it would require the login fields to
be named correctly.
The only way that I can think to do it is to have the plugin add some
new runmodes to the module! Does anyone have any suggestions on how
to do that cleanly? Is it even wise?
I think the right thing to do here is to have default login,
forbidden, and logout runmodes that the Auth plugin adds to the app
(maybe prefix the runmode names with auth_ so we worry less about
clashing with other runmode names). Then an application can override
these methods to present a custom screen.
Anyway, Drew, if you (or anyone else for that matter) is willing to
colaborate on an Auth module, I would be happy to help out.
Definitely! Do you have a publically available version control
repository? I just have subversion running on my laptop. Is it worth
setting up a sourceforge project (and how much work is it anyway)?
Drew
--
Drew Taylor * Web development consulting
Email: [EMAIL PROTECTED] * Site implementation hosting
Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Re: [cgiapp] User authentication
On Fri, 29 Oct 2004 09:46:33 -0400, Michael [EMAIL PROTECTED] wrote: Owain wrote: Now, this is where I definitely disagree. It's so easy for me to use mod_perl authentication (especially using C::A::P::Dispatch). You can be as granular or as top-level as you want. I just don't understand the ISP argument since root level servers are just $30 a month. That's serveral dozen low traffic domains. Or one or two mid level. If you don't want to deal with complete machine control, you can have virtual servers starting at $15 a month. Do you have a company you can recommend at the $30/month level? I'd love to have a mod_perl enabled server. I currently have a webmaster account with pair.com that is $28/mo. But I'm rather addicted to the nice admin interface they have for adding domains, mail, etc. I know it makes me less of a geek but... Crud checking at the entity being viewed/updated/ for the user since this allows you to re-use the rm code and html template code. E.g. a user can change their own address details but not others, even though they may be able to see them. Think of a user directory kind of thing. Going back the question above about rm-level auth. If you abstract your CRUD functions to your DAO (Class::DBI, etc) then having you can still reuse the majority of the code and templates. I'm going to disagree here. Going back to Owain's example, I don't want a user to edit someone else's profile. Or maybe I don't even want to show the edit form in the first place. Perhaps I'll show the display version instead. Pushing that functionality down into CDBI seems inappropriate. I might have checks in my CDBI model to prevent accidental screwups to be paranoid, but you also need the information on the application level so it can determine if a screen is appropriate for a given user. Drew -- Drew Taylor * Web development consulting Email: [EMAIL PROTECTED] * Site implementation hosting Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
On Fri, 29 Oct 2004 11:43:34 +0100, Owain [EMAIL PROTECTED] wrote:
Run mode level authentication is preferable otherwise in your example it
looks like you would need separate your non-authenticated run modes out into
another CGA module (+ instance scripts etc) even though they are just a
different view on of same application model. If you get rm-level security
right you get application security for free!
My thought exactly. I'm working on a shopping cart, and this sort of
security is very important.
A point I would like to add is that the documentation on the wiki strongly
suggests doing authentication using the app server and not in your
application. This (I think) would not provide the necessary granularity for
run-mode level security and also using a consumer(ish) ISP they do not allow
me access to httpd.conf to install my own modules etc.
The thing I'm still unsure about is how to go from the application
level security to runmode level security. So I have an
authentication() method that does checking at the application level.
But how do you go down to runmode level? It seems reasonable to have a
standard method name that authentication() calls (if present). Perhaps
auth_rm_$runmode()? Then authentication might look like this:
sub authentication {
my $self = shift;
# do application level security
my $rm = $self-get_current_runmode;
if (my $rm_auth = $self-can(auth_rm_.$rm)) {
$rm_auth($self);
}
}
I do often wonder whether I should do all my authentication using some sort
of generic directory service rather than mucking about with my own user
tables, group tables and so forth. Another plugin for your plugin to
support directories?
Interesting idea. Are you talking about using LDAP or the like to
handle it? I have zero experience with LDAP, so I'll have to defer on
that one. But the idea is certainly a good one.
Drew
--
Drew Taylor * Web development consulting
Email: [EMAIL PROTECTED] * Site implementation hosting
Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User Auth Plugin Question
On Fri, 29 Oct 2004 08:45:31 -0400, Jason Purdy [EMAIL PROTECTED] wrote: Also, when it comes to user authentication, when I dabbled in that, I came across Apache::AuthCookie[2], which in my opinion is a GREAT way to handle user auth. It separates the whole authentication code away from your application code and you can easily protect your application within Apache's configuration for your application's location. I've used A::AuthCookie in the past, and I agree that it was very easy to do once I got my head wrapped around it. But what it won't give us is the finer grained permissions/authentication I talked about in later replies on the authentication thead. So AuthCookie might be a good front door, but I also want individual locks on each bedroom doors. Drew -- Drew Taylor * Web development consulting Email: [EMAIL PROTECTED] * Site implementation hosting Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [OT] Multiple constraints on field (DFV)
- Original Message -
From: Michael [EMAIL PROTECTED]
To: Jonathan Mangin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, October 28, 2004 3:08 PM
Subject: Re: [cgiapp] [OT] Multiple constraints on field (DFV)
Jonathan Mangin wrote:
Is it possible to put multiple constraints on an input field?
For instance:
constraints = {id = qr/[A-Z0-9]{3,11}/,
and also:
substr($id,0,2) eq $state_abbrev
something like...
constraints = {
id = sub {
my $id = shift;
return ($id =~ /[A-Z0-9]{3,11}/ (substr($id,0,2) eq $state_abbrev));
}
}
--
Michael Peters
Developer
Plus Three, LP
Exactly like that, as it turns out. Thanks Michael.
I don't know how many (or exactly what) @_ contains. (Tried a few $_[?])
This seems to work. Could it be better for (possibly) more variables?
my ($results, $err_page) = $self-check_rm('page1',
page1_profile($state_abbrev);
sub page1_profile {
my $state_abbrev = pop(@_);
return {
required = [qw/uid comp_id/],
constraints = {uid = qr/\w{6,14}/,
comp_id = sub {
my $comp_id = shift;
return (
$comp_id =~ /[A-Z0-9]{3,14}/
substr($comp_id,0,2) eq $state_abbrev
)
}
},
msgs = {any_errors = 'some_errors',
prefix = 'err_'}
};
}
Thanks again,
--Jon
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
On Fri, 29 Oct 2004 10:25:59 -0400, Michael [EMAIL PROTECTED] wrote: While recognizing that tmtowtdi, this is how I deal with situations like the above... Using CGI::Application::Dispatch I would have a urls like these Interesting module. I've looked at it in the past but will investigate further this weekend. It looks like a good front end to lots of varied functionality, and gives you prettier URLs to boot! /app/reports/general /app/reports/download /app/reports/detail /app/reports/geo_plot So even if they were all in the same module, my auth handler could still provide such granularity. Location /app/reports/general Require group reports_general /Location Or something like that. You would define what the 'group reports_general' is in your auth handler. Could you give us an idea of what your Auth handler (I'm assuming you are using PerlHandler Auth My::Auth in your httpd.conf) looks like. It's an interesting idea. How do you handle (if at all) authorization to an individual report within the /app/reports/general group? I'm assuming your auth handler takes the value of the Require directive and does authentication with that value on some data repository. Drew -- Drew Taylor * Web development consulting Email: [EMAIL PROTECTED] * Site implementation hosting Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
Drew Taylor wrote: On Fri, 29 Oct 2004 09:46:33 -0400, Michael [EMAIL PROTECTED] wrote: Owain wrote: Now, this is where I definitely disagree. It's so easy for me to use mod_perl authentication (especially using C::A::P::Dispatch). You can be as granular or as top-level as you want. I just don't understand the ISP argument since root level servers are just $30 a month. That's serveral dozen low traffic domains. Or one or two mid level. If you don't want to deal with complete machine control, you can have virtual servers starting at $15 a month. Do you have a company you can recommend at the $30/month level? I'd love to have a mod_perl enabled server. I currently have a webmaster account with pair.com that is $28/mo. But I'm rather addicted to the nice admin interface they have for adding domains, mail, etc. I know it makes me less of a geek but... I use serverpronto.com. If you want the point and click interface, they do give you webmin for free. If you are going to play with mod_perl I would recomend that you don't use webmin for apache, but it should work fine for email, etc. Its $30 a month. I haven't had a single problem with them. I'm sure others might have other ideas on virtual hosts, etc. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
You know, I was talking with a friend of mine about this sort of thing the other day, because I was working on an auth scheme for a project of mine, and wanted some way of making it as pluggable as possible, as far as permission storage backends go. It is quite possible that the language I am using here is messy, for which I apologize in advance. I am unaware of a widely used standard for authentication. I know of a few such projects that are under discussion, but it would be nice to have a standard api. I am thinking of something like this: A runmode would have some sort of flag that would indicate that it requires authentication. If it does, it asks some other module whether or not it is allowed to go ahead. Probably it would need some way of identifying the user that is performing the action. The other module would want to have some sort of ID passed to it for the user, and some sort of information about the task/job/runmode/whatever that the user is trying to do. It would return a response of OK if the user is authenticated and allowed, NOT if the user is not allowed to perform this task, or AUTH if the user needs to be authenticated. (Perhaps redirecting to an auth runmode, perhaps not. I'd suggest not.) That other module is the tricky part. I think it would be handy to have this sort of thing, and it allows folks to build connections between that auth checker app and whatever auth/permission store they want. LDAP, XML, unix perms, apache, you name it. Does this make a degree of sense, or am I way the heck out in left field? caleb On Fri, 29 Oct 2004 11:48:24 -0400, Drew Taylor [EMAIL PROTECTED] wrote: On Fri, 29 Oct 2004 10:25:59 -0400, Michael [EMAIL PROTECTED] wrote: While recognizing that tmtowtdi, this is how I deal with situations like the above... Using CGI::Application::Dispatch I would have a urls like these Interesting module. I've looked at it in the past but will investigate further this weekend. It looks like a good front end to lots of varied functionality, and gives you prettier URLs to boot! /app/reports/general /app/reports/download /app/reports/detail /app/reports/geo_plot So even if they were all in the same module, my auth handler could still provide such granularity. Location /app/reports/general Require group reports_general /Location Or something like that. You would define what the 'group reports_general' is in your auth handler. Could you give us an idea of what your Auth handler (I'm assuming you are using PerlHandler Auth My::Auth in your httpd.conf) looks like. It's an interesting idea. How do you handle (if at all) authorization to an individual report within the /app/reports/general group? I'm assuming your auth handler takes the value of the Require directive and does authentication with that value on some data repository. Drew -- Drew Taylor * Web development consulting Email: [EMAIL PROTECTED] * Site implementation hosting Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- caleb http://www.ruejulesverne.com - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] ANNOUNCE - CGI::Application::Dispatch 0.03
The uploaded file
CGI-Application-Dispatch-0.03.tar.gz
has entered CPAN as
file: $CPAN/authors/id/W/WO/WONKO/CGI-Application-Dispatch-0.03.tar.gz
size: 6283 bytes
md5: 359c581028d7bb24a5ffc2cad046626e
changes in this release include:
- fixed build on some systems
- minor optimizations
If you can't wait for your favorite cpan mirror to pick it up, you can
get it at -
http://people.plusthree.com/~mpeters/CGI-Application-Dispatch-0.03.tar.gz
NAME
CGI::Application::Dispatch - Class used to dispatch request to
CGI::Application based objects
SYNOPSIS
Under mod_perl
Location /app
SetHandler perl-script
PerlHandler CGI::Application::Dispatch
/Location
Under normal cgi
#!/usr/bin/perl
use strict;
use CGI::Application::Dispatch;
CGI::Application::Dispatch-dispatch();
DESCRIPTION
This module provides a way (as a mod_perl handler or running under
vanilla CGI) to look at the path ($r-path_info or $ENV{PATH_INFO}) of
the incoming request, parse off the desired module and it's run mode,
create an instance of that module and run it.
It will translate a URI like this (under mod_perl):
/app/module_name/run_mode
or this (vanilla cgi)
/app/index.cgi/module_name/run_mode
into something that will be functionally similar to this
my $app = Module::Name-new(..);
$app-mode_param(sub {'run_mode'}); #this will set the run mode
--
Michael Peters
Developer
Plus Three, LP
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] radio_group
Guru's I have a C::A application where I'm using radio_group method for a form. When the form is displayed, the first option is selected by default. I want to change this behavior and no option should be select by default. How can I make this change? Setting -default = is not getting me the result I wanted. Any help will be great. Thanks for your time and help in advance. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] User authentication
On Fri, 2004-10-29 at 16:36, Drew Taylor wrote:
On Fri, 29 Oct 2004 11:43:34 +0100, Owain [EMAIL PROTECTED] wrote:
Run mode level authentication is preferable otherwise in your example it
looks like you would need separate your non-authenticated run modes out into
another CGA module (+ instance scripts etc) even though they are just a
different view on of same application model. If you get rm-level security
right you get application security for free!
My thought exactly. I'm working on a shopping cart, and this sort of
security is very important.
A point I would like to add is that the documentation on the wiki strongly
suggests doing authentication using the app server and not in your
application. This (I think) would not provide the necessary granularity for
run-mode level security and also using a consumer(ish) ISP they do not allow
me access to httpd.conf to install my own modules etc.
The thing I'm still unsure about is how to go from the application
level security to runmode level security. So I have an
authentication() method that does checking at the application level.
But how do you go down to runmode level? It seems reasonable to have a
standard method name that authentication() calls (if present). Perhaps
auth_rm_$runmode()? Then authentication might look like this:
sub authentication {
my $self = shift;
# do application level security
my $rm = $self-get_current_runmode;
if (my $rm_auth = $self-can(auth_rm_.$rm)) {
$rm_auth($self);
}
}
Well, there was this posting on the list about Auto run mode:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02266.html
which looks quite a tidy way of flagging runmodes rather than creating
some sort of hash to map runmodes to authentication requirements.
So perhaps something like:
sub my_run_mode : Authenticate {
# do something here
}
may work. I am not sure how it would work if you stacked this sort of
thing regards a plug-in picking this up. e.g. would it be:
sub my_run_mode : Runmode : Authenticate: SomethingElseInFuture {
# do something here
}
and could the suite of plug-ins cope with all of this extra sub stuff?
Also, I am not sure if you could pass a parameter in this way... it
always ceases to amaze me with Perl that it will enumerate stuff so
perhaps something like this might twork:
sub my_run_mode : Authenticate($user) {
# do something here
}
I do often wonder whether I should do all my authentication using some sort
of generic directory service rather than mucking about with my own user
tables, group tables and so forth. Another plugin for your plugin to
support directories?
Interesting idea. Are you talking about using LDAP or the like to
handle it? I have zero experience with LDAP, so I'll have to defer on
that one. But the idea is certainly a good one.
Drew
Absolutely, something like Ldap to handle all of the security related
application meta-data. How much better would it be to integrate into a
corporate directory to handle this. No experience myself but all of
this does have a hint of re-inventing the wheel. Is there an LDAP
server that is freely available? Should it be a subclass of the
proposed plug-in? What are the calls you can make to a directory
service?
That's me done for the moment. I have to step out for a week or so
since being a European I have to execute
Time::Vacation::Family::Golf::MyParents::Cyprus::EdgyWife
O.
Re: [cgiapp] AutoRunmode plugin updated to use callbacks
sub setup{
my $self = shift;
$self-use_plugin('::AutoRunmode');
}
where use_plugin() would use the plugin and call some install
method to let it set itself up.
I like the idea of making it less verbose. I haven't actually looked
at the callback implementation, but is it not possible to have the
used plugin just install itself? Why can't
use CGI::Application::Plugin::AutoRunmode;
just do the right thing and install all of the hooks, callbacks, etc
that it needs to do? This would be really non-verbose.
That would be the Perl way, yes.
I tried to do that actually.
But use happens at compile time, whereas $self-add_callback is
called on the CGI::App instance at runtime (and cannot be done
with a use -- at least as far as I can see).
Should we have support for compile-time add-callbacks?
I think not.
Things are already getting a little more complex and we do not want to
add a steep learning curve to CGI::App, I hope.
So I think having a install method that plugin writers can supply and
that gets called automatically, would be a good compromise.
(It is really only a problem for plugin writers, if you want to add
callbacks to your own application, you can just do so in setup(), no
need
to make extra code disappear with some behind-the-scenes magic)
Thilo
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
