Re: [cgiapp] Authz with Authen, something is backwards here...
Hi Brett,
Authorization is not purely related to authentication. For example
you could authorize access based on an IP Address, or based on the
time of the day. So we can't automatically decline a request just
because they are not logged in.
But as you say, your authentication checks should have caught this
before it got this far. Perhaps there is a problem with the order in
which you configured things which will influence the order in which
the authen and authz callbacks get triggered.
Cheers,
Cees
On Thu, Jun 14, 2012 at 6:03 AM, B. Estrade estr...@gmail.com wrote:
On Wed, Jun 13, 2012 at 02:58:28PM -0500, B. Estrade wrote:
I am finding that if I have a runmode that is protected via
authentication and authorization, the authen doesn't happen before the
authz is validated.
In otherwords, I want a authen to happen first; if it fails, redirect
to the login. If authen is okay, proceseed to authz.
Right now I have this unsettling bit of code in my authz driver's
authorize_user method:
sub authorize_user {
my $self = shift; my ($username, $required_permission) = @_;
return 1 if (!$username or $required_permission);
I mean:
sub authorize_user {
my $self = shift;
my ($username, $required_permission) = @_;
return 1 if (!$username);
I figure that if there is no $username, then authen has failed. But,
because of the ordering of calls, it appears that if this is the case,
I have to succeed authorize_user and rely on authen to redirect the
login - this seems backwards. Authen should fail before anything is
checked with authz. What am I doing wrong?
Thank you,
Brett
# CGI::Application community mailing list
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
# CGI::Application community mailing list
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] CAP::Session causing errors under FastCGI and Plack?
On Wed, Apr 4, 2012 at 1:51 PM, Jason Crome cromed...@gmail.com wrote:
I keep banging my head against the wall trying to figure this out. I expect
that I am doing something else wrong, but whenever I comment out the session
initialization logic, my app runs (as well as it can without sessions, that
is).
I am getting this error under FCGI and PSGI:
[Dispatch] ERROR for request '/': Unknown error: Error executing class
callback in init stage: Calling session_config after the session has already
been created at
/Users/crome/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/CGI/Application/Plugin/Session.pm
line 79.
Hi Jason,
Does this happen every time? Or does the first request succeed and
then subsequent requests fail? Does it have any problems when you run
it as a plain old CGI?
The big question for me is: Are you getting a new CGI::Application
object on every request, or is the object from the previous request
being re-used? If the object is being re-used, then it is not being
cleared out properly and hence the CAP::Session module thinks the
session has already been loaded when cgiapp_init calls session_config.
CAP::Session looks to see if $self-{__CAP__SESSION_OBJ} exists to
determine if a session has already been loaded. At the start of your
cgiapp_init method, look to see if it exists already which should
point you in the right direction to figuring out what is going on.
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Authentication/Authorization prerun interaction
On Thu, Jan 12, 2012 at 5:18 AM, Lyle Brooks bro...@deseret.com wrote:
Quoting Cees Hek (cees...@gmail.com):
On Wed, Jan 11, 2012 at 5:40 AM, Lyle Brooks bro...@deseret.com wrote:
The problem here is that Authorization does not necessarily have
anything to do with Authentication. You could authorize someone based
on the IP address that they came from for instance.
Yes, I can understand that point. However, I would think that the
case where Authorization is used in conjunction with Authentication
would often be a far more prevalent 'use case'. No hard data to back
this up...just my gut feel.
Yes, I would agree with that.
The quick solution is to short circuit your code so that authorization
checks are only executed when a user is authenticated. You didn't
provide any code so I can't be sure if that is easy or not...
There's not much code to provide. I pretty much use the modules by
taking all the defaults.
...
In the Application's cgiapp_init() method I have two calls..
$self-authen-protected_runmodes( qw( display process ) );
$self-authorization-authz_runmodes(
display = 'admin',
process = 'admin',
);
I tend to do authorization the following way:
__PACKAGE__-authz('group')-config(
DRIVER = [ 'Generic', sub {
my ($username,$group) = @_;
return MyApp-user($username)-in_group($group);
} ],
);
# Only administrators can access anything in this module
__PACKAGE__-add_callback('prerun', sub {
my $self = shift;
return $self-forbidden unless
__PACKAGE__-authz('group')-authorize('administrator');
});
-or-
# Only administrators can run this runmode
sub admin_something {
my $self = shift;
return $self-forbidden unless
__PACKAGE__-authz('group')-authorize('administrator');
...
}
Authentication is handled in Apache using Apache2::AuthCookie which is
probably why I can't come across this problem before.
Seems to me in this very basic case, that an unauthenticated user
should be given the opportunity to authenticate. As it now stands,
the Forbidden page is returned...and the user (even one who would
be authorized to access the runmodes) is never the opportunity to
authenticate...and hence then be judged to be authorized).
This is why I argue that a change should be made to allow the
authentication (via the prerun mode) be given precedence over the
authorization's Forbidden response.
Yup I agree
From my reading of the CGI::Application's documention on the
use of prerun_mode(), its purpose is to allow for a new runmode
to supercede the requested runmodein which case, it seems
like it should as a byproduct also set $self-{__CURRENT_RUNMODE}
In CGI::Application::prerun_mode() replace the line
$self-{__PRERUN_MODE} = $prerun_mode;
with
$self-{__PRERUN_MODE} = $self-{__CURRENT_RUNMODE} = $prerun_mode;
(which I think would address my issue).
You could test that easily by copying the prerun method into your
application and adding your patch.
I think this is probably the most appropriate way to solve this issue.
The plugin should be able to ask CGI::Application 'What is the
runmode that you are about to execute, without having to do multiple
checks.
I don't what impact that would have on existing code written
for CGI::Application.
Neither do I, but I would suspect it would be minimal (does anyone
else have any comments on this?)
If that approach turned out to be inappropriate, then I would
in CGI::Application::Plugin::Authorization::prerun_callback()
the line
if ($rule = $auth-is_authz_runmode($self-get_current_runmode)) {
be replaced with something like...
my $candidate_runmode = $self-prerun_mode() || $self-get_current_runmode();
if ($rule = $auth-is_authz_runmode($candidate_runmode)) {
This brings me back to my comment above. Why should the plugin have
to check in multiple places to find out what runmode is about to be
executed?
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Authentication/Authorization prerun interaction
On Wed, Jan 11, 2012 at 5:40 AM, Lyle Brooks bro...@deseret.com wrote:
I am attempting to use both
CGI::Application::Plugin::Authentication
and
CGI::Application::Plugin::Authorization
and when I attempt to restrict a runmode to require authorization (and
authentication), it produces a result I find counter-intuitive.
I was wondering if anyone had similar experiences.
The conditions occurs when I restrict a runmode to an authorized
group, and attempt to access it the first time (without authenticating).
What I think should happen is that when I attempt to access the
runmode, I should be redirected to a login form to be authenticated.
The problem here is that Authorization does not necessarily have
anything to do with Authentication. You could authorize someone based
on the IP address that they came from for instance.
However, what actually occurs is that I get a Forbidden page.
When I dug down into the code, it seems this is due to how the Plugin
modules interact with the prerun mode.
When the request comes in, the prerun_callbacks that the Authentication
and Authorization registered are called before the requested runmode
code is executedall good so far.
The Authentication plugin will set the prerun_mode to authen_login
by default. The effect of this, as I understand it,
is to substitute the authen_login runmode for the requested runmode,
which effectively requires the user to authenticate. So far so good.
Then the Authorization plugin callback is run. In this section
of code, it checks get_current_runmode() which returns the original
requested runmodenot the authen_login runmode set by the upstream
authentication plugin.
And at this point, the authorization plugin judges the request to
be unauthorized, and it will then make a call to the redirect_to_forbidding
runmode which returns the Forbidden page I mentioned earlier.
So the Authorization plugin ends up taking action, before the prerun_mode
(set the the Authentication plugin) can be acted on later down the
request cycle.
So if the login form (instead of a forbidden page) should be returned,
what should be the appropriate remedy?
The quick solution is to short circuit your code so that authorization
checks are only executed when a user is authenticated. You didn't
provide any code so I can't be sure if that is easy or not...
Should setting the prerun_mode() also set $self-{__CURRENT_RUNMODE}
inside of CGI::Application?
I am sure this is something that has been discussed in the past and
was avoided for some reason that I can't remember... Have a look
through the archives. I can't immediately see a problem with doing
this and it makes a certain amount of sense, but I may be missing
something.
or
Should CGI::Application::Plugin::Authorization::prerun_callback be
modified to check the setting of prerun_mode() before get_current_runmode()?
This seems reasonable enough, but I am hesitant to just make that
change without knowing what consequences that might have for existing
users.
I hope that is understandable. Any ideas other could share would
be appreciated.
My suggestion would be to try and handle this in your own code as I
mentioned above. If your authorization checks depend on someone being
logged in, then only run the checks when someone is logged in.
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] $self-tt_error() ?
The plugin throws an error if processing a template fails. So you can
wrap your calls to tt_process in an eval and catch any errors.
my $output = eval { $self-tt_process({}) };
if ($@) {
# Something went wrong
} else {
return $output
}
I generally just let these errors bubble up and let the
CGI:Application error handler deal with it.
Cheers,
Cees
On Thu, May 19, 2011 at 11:35 PM, gvim gvi...@gmail.com wrote:
I'm using CA::Plugin::TT and there's no mention in the docs of a
corresponding method for $tt-error(), ie. $self-tt_error().
gvim
# CGI::Application community mailing list
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] hook question
On Fri, Jul 30, 2010 at 7:58 AM, Todd Ross tar.li...@yahoo.com wrote:
I understand the distinction between compile time and run time (as phases),
but
I'm not fully appreciating the impact here; I'm still a little lost.
Hi Todd,
You are actually running into a couple of problems, one of them is
what Michael has described, and the other is that the callback code
will not run the same callback method multiple times at the same hook
location. You are hooking the same method three times, but it will
only ever be executed once.
So, place your instance code at the end of the file, and create a
separate callback for each call to add_callback and you will see that
it does work (ideally though, you should be placing your packages into
separate files as it will save you many headaches down the road --
especially when working with mod_perl or other persistant perl
processes):
#!/usr/bin/perl
use strict;
use warnings;
package Private::Webapp;
use base 'CGI::Application';
__PACKAGE__-add_callback('prerun', sub { print STDERR hook_prerun 1\n });
Private::Webapp-add_callback('prerun', sub { print STDERR hook_prerun 2\n });
sub setup {
my $self = shift;
$self-start_mode('begin');
$self-mode_param('rm');
$self-run_modes(
begin = 'do_begin'
);
$self-add_callback('prerun', sub { print STDERR hook_prerun 3\n });
}
sub do_begin {
my $self = shift;
my $output = Hello, CGI::Application!\n;
return $output;
}
package main;
my $webapp = Private::Webapp-new();
$webapp-run();
1;
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Authentication cant find my driver
On Sat, Jun 19, 2010 at 12:51 AM, Jerry Kaidor je...@tr2.com wrote: I'm trying to create a new driver for CAP::Authentication. When I run my program, it says: --- snip -- Error executing class callback in prerun stage: Driver MULTI_DBI can not be found at /usr/lib/perl5/site_perl/5.10.0/CGI/Application/Plugin/Authentication.pm line 1096. - endsnip --- I put my driver ( MULTI_DBI.pm ) in the same directory as the existing drivers. It has the same ownership and permissions as the existing drivers. What does your 'package' line at the top of your module look like? It should be: package CGI::Application::Plugin::Authentication::Driver::MULTI_DBI; Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Internationalization with Locale::Maketext
On Thu, May 27, 2010 at 6:29 AM, Jerry Kaidor je...@tr2.com wrote: Jani-Hur wrote I'm new to web programming. Thanks to economical turmoil I've plenty of free time *** I've been meaning to write an intro post myself. Like in the AA meetings: My name is Jerry Kaidor, and I'm a programmer... Well, I used to be a programmer. Did it for a living for 20 years. Mostly embedded systems, networking equipment, lots of C and assembler. Hi Jerry, Looks like your post got buried inside this thread :) I would like to ultimately wind up with an MVC organization. But it seems to be too much work to rebuild the whole thing from scratch as a new project. For now, I am using CGI::Application to strip out the giant if-elsif statements for the CGI state machines. It's a major change. So today's sub project is to get the whole mess under source code control. For a one-man project I don't need anything fancy, so will just use CVS. Looks like you are the right track in refactoring your code. Replacing the old-school giant if/else block with a proper dispatch solution like CGI::application is definitely the right move. As for source code control, might I suggest subversion over CVS. They use the same basic underlying principles but subversion seems to be much more mature and robust (although I haven't looked at CVS in over 10 years, so perhaps things have changed for the better). Also, a lot of people swear by 'git' so it would be worth a look as well. Good luck in your endeavors... Cheers, Cees Hek # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Simple as replacement for CGI not working?
On Thu, Nov 19, 2009 at 5:59 AM, Richard Jones ra.jo...@dpw.clara.co.uk wrote: App working fine with default CGI, but decided to see if it works with CGI::Simple using the cgiapp_get_query() override. But instead of rendering the page I get a popup: 'you have chosen to open myapp_server.pl which is a Perl script ... what should Firefox do with this file'. I can't fathom where the problem lies. Anyone been there before? I seems like maybe you aren't sending a content type header... LWP comes with a command line script called GET which is handy for fetching pages and looking at headers (there are also useful firefox plugins for this too). Try this from your shell: GET -ed http://mysite/myapp_server.pl That will dump the response headers to the screen. Check to make sure the content-type is correct. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] UTF-8 output
On Wed, Nov 4, 2009 at 6:15 PM, Michael Lackhoff
lackh...@zbmed.uni-koeln.de wrote:
On 03.11.2009 23:27 Cees Hek wrote:
However, I guess you should ensure that any data that you send to TT
is utf8 encoded.
That's exactly the problem. I pass lots of RDBO objects into the
templates and those should contain decoded (UTF-8 flag on) data, not
UTF-8 octets, so I guess encoding the whole thing at the end might be
the only practical option left in this situation.
Can't you get DBI to do the decoding for you? I think it will depend
on the DBD module you use, but it is quite easy with PostgeSQL:
http://search.cpan.org/dist/DBD-Pg/Pg.pm#pg_enable_utf8_(boolean)
I use Rose::DB as well and have the following in my base class:
__PACKAGE__-register_db(
domain = 'development',
type = 'main',
driver = 'Pg',
database = $NC::Config::database,
username = $NC::Config::database_username,
password = $NC::Config::database_password,
host = $NC::Config::database_host,
port = $NC::Config::database_port,
server_time_zone = 'Australia/Sydney',
european_dates = 1,
# Apache::DBI and Rose::DB choke when server side prepares are turned on
connect_options = {
pg_server_prepare = 0,
pg_enable_utf8= 1,
},
post_connect_sql = SET CLIENT_ENCODING TO 'UTF8';,
);
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] UTF-8 output
On Wed, Nov 4, 2009 at 9:49 PM, Michael Lackhoff
lackh...@zbmed.uni-koeln.de wrote:
On 04.11.2009 11:24 Cees Hek wrote:
Can't you get DBI to do the decoding for you? I think it will depend
on the DBD module you use, but it is quite easy with PostgeSQL:
I am using SQLite and it is also quite easy there but then I have -- as
you say -- _decoded_ values. This is what I want within my application
but as soon as I produce some output (let CGI::Application print the
template with embedded DB data) Perl does its evil magic and encodes
everything to latin1 -- at least this is what I get.
Do you do some magic with STDOUT or how do you get the UTF-8 to the
browser? Whatever I try, Perl always outputs latin1 from decoded strings
and the only remedy I found was to not let it output decoded strings but
encoded UTF-8 octets.
You mean something like this:
__PACKAGE__-add_callback('postrun', sub {
my $self = shift;
# Make sure the output is utf8 encoded if it needs it
if ( $_[0] ${$_[0]} utf8::is_utf8(${$_[0]}) ){
utf8::encode( ${$_[0]} );
}
return;
});
I have that in my CGI::App base class.
Sorry for the long thread but this is a horror I encounter over and over
again and I am hoping for a better understanding to get it right once
and for all.
Not a problem. Utf8 support is tricky to get right, and I am still
not sure if I have tackled everything myself. I'm sure others will
get something out of the discussion as well.
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] UTF-8 output
On Wed, Nov 4, 2009 at 12:15 AM, Michael Lackhoff lackh...@zbmed.uni-koeln.de wrote: On 03.11.2009 01:22 Cees Hek wrote: Have a look at this perlmonks post by Rhesa: http://www.perlmonks.org/?node_id=651574 Thanks Cees (and of course Rhesa), this is exactly what I need! Since you are the author of CAP::TT, may I also ask how and when you do the encoding of the template output? Is utf8::encode in postprocess the way to go? Template Toolkit works fine with utf8 templates, so I don't think you need to encode the template output yourself. if your template files contain a BOM at the start then you don't need to do anything, or you can set the ENCODING option to 'utf8' manually. See this FAQ entry for the details. http://search.cpan.org/dist/Template-Toolkit/lib/Template/FAQ.pod#Why_do_I_get_rubbish_for_my_utf-8_templates? However, I guess you should ensure that any data that you send to TT is utf8 encoded. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] UTF-8 output
On Tue, Nov 3, 2009 at 3:23 AM, Michael Lackhoff lackh...@zbmed.uni-koeln.de wrote: Sounds very interesting. Let me try to follow: I am in the process of changing the db connection as well but have still some problems with CGI params. How do you decode them? Not one at a time, I guess? In my app they seem to be encoded twice after a roundtrip (have to do more debugging). Have a look at this perlmonks post by Rhesa: http://www.perlmonks.org/?node_id=651574 Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] [patch] CAP::MessageStack + CAP::FormState
On Tue, Oct 20, 2009 at 12:51 AM, Michael Graham ma...@the-wire.com wrote: We should be able to detect the use of HTML::Template with $self-tmpl_class. BUT, both CAP::TT and CAP::AnyTemplate call the load_tmpl hook, and neither of them sets $self-tmpl_class(). There may be other templating plugins out there that do the same. So using this approach, FormState will *always* think that the template class is HTML::Template. I am happy to set that parameter in CAP::TT if you like. It makes sense for there to be a way for plugins to know what templating system is being used. It does bring up another question though. What do I set it to? It is not a method that CAP::TT would call itself, so I guess just setting to to 'Template::Toolkit' would make the most sense. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] packages autouse?
Are you perhaps looking for Class::Autouse? Not something I would use myself, but it may help you be more lazy in your programming... Cheers, Cees On Fri, Jun 12, 2009 at 2:11 AM, Porta julian.po...@gmail.com wrote: Hey, folks. Question: I was wondering if anyone else (than me) thinks is annoying to declare the use of all the required models (objects? packages?) you're using in your CA app?More, when working with CAD, on each controller you need to repeat use MyApp::Foo; use MyApp::Bar; etc. Assuming you're working with a persistent instance (means no need to do a cold start of your app on each request, so no problem to load all your app packages in memory) why not have *something* to manage the use of all the involved packages and reduce the repeated code on each package start. Thoughts? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Redirecting with CGI::App Problem (possibly mod_perl related)
Hi Brad,
Try moving your code to the prerun stage, and look at the examples in
CGI::Application::Plugin::Redirect. The first example in the docs is pretty
much what you want:
use CGI::Application::Plugin::Redirect;
sub cgiapp_prerun {
my $self = shift;
if ( not logged in ) {
return $self-redirect('login.html');
}
}
Cheers,
Cees
On Tue, May 5, 2009 at 2:25 PM, Brad Van Sickle bvs7...@gmail.com wrote:
I'm running under mod_perl, not sure if that's relevant here or not... I
think it is because I've been able to get this working in a non-mod_perl
envrionment previously...
I'm attempting to validate a user's session in my cgi::app script. If the
session cookie is not present, or the session is invalid, I want to redirect
the user to the login module to get authenticated. The order of
operations document has a nice example of how to do this from within init,
but printing out the redirect headers and than issuing a die() to prevent
the rest of the operations from executing.
This does not work for me. As soon as that die executes my script fails
with the error:
Error executing class callback in init stage: Died at blah blah blah
my code: if (!$ValidSession)
{
use CGI::Application::Plugin::Redirect;
$self-teardown();
print $self-redirect($FailureLocation);
die;
}
I've read every bit of documentation I can find and tried everything I can
think of... I could really use some suggestions at this point.
Thanks!
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Redirecting with CGI::App Problem (possibly mod_perl related)
You can only call $self-redirect in a prerun method or in a runmode. Are you sure that is where you are calling it? If you call it in init it will not work as expected. Cheers, Cees On Tue, May 5, 2009 at 2:40 PM, Brad Van Sickle bvs7...@gmail.com wrote: Thanks for the quick response! Unfortunatnly, if I use that method the rest of the script still executes and the redirect headers seem to print after the html/html tags html my templated html /body /html !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title200 OK/title /headbody h1OK/h1 pThe document has moved a href=my_urihere/a./p hr addressApache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.8 mod_perl/2.0.4 Perl/v5.8.8 Server at xxx.xxx.xxx.49 Port 80/address /body/html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CAP::Authentication
On Tue, Mar 17, 2009 at 5:11 AM, Terrence Brannon tbran...@insuranceagents.com wrote: Does cgiapp throw 404 errors? I've never seen it do that. What exactly does your webserver log say? It would be nice if there were a verbose trace option for cgiapp's resolution of request into runmode. CAP::LogDispatch can trace the execution path of your program. Check out the LOG_METHOD_EXECUTION option in the docs. Not sure if that was exactly what you were looking for but it gives a good indication of what your program is doing... Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CAP::Authentication
On Tue, Mar 17, 2009 at 3:14 AM, fREW Schmidt fri...@gmail.com wrote:
Hi!
We are trying to use CAP::Authentication and in general it works fairly
well. I am trying to make a new LOGIN_RUNMODE though and it just doesn't
seem to work.
Here's my code:
__PACKAGE__-authen-config(
DRIVER = [ 'Generic', { user1 = '123' } ],
LOGIN_RUNMODE = 'login',
);
__PACKAGE__-authen-protected_runmodes(qr/^(?!main)/);
sub login : Runmode {
my $self = shift;
$self-header_add( -status = '500 unauthenticated' );
return $self-json_body({ success = 'false', reason =
'unauthenticated'});
}
Clearly I am not doing anything very special, but for some reason I am
getting a 404 error. I tried all of these:
LOGIN_RUNMODE = 'login',
LOGIN_RUNMODE = 'controller/login',
LOGIN_RUNMODE = '/controller/login',
LOGIN_RUNMODE = '/ACD/controller/login',
Getting a 404 with the LOGIN_RUNMODE option sounds very strange. All
the LOGIN_RUNMODE option does is change the current runmode to what
you specified if the user is not authenticated (search for the
'redirect_to_login' method in the code). That means that in the
current application you need a 'login' runmode which returns your
login form (and it looks like you have that).
Perhaps you are already doing some runmode manipulation at the prerun
level which is conflicting. How are you managing the path_info to get
your runmode? Are you using Dispatch, or the built in
CGI::Application support, or your own home rolled solution?
You can also get to a custom login page by providing a url which will
do a redirect to the new page, so maybe the following will work for
you:
LOGIN_URL = '/ACD/controller/login',
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] CGI::Application::Plugin::Authentication - how to get at the CGI::Application object instance?
On Fri, Mar 6, 2009 at 3:30 AM, Terrence Brannon
tbran...@insuranceagents.com wrote:
Is there any way to access the CGI::Application object from a closure being
used with the Generic driver?
Because you configure the call to the closure at package-level, it is not
obvious how to supply it to the closure:
__PACKAGE__-authen-config(
DRIVER = [ 'Generic', \check_password ],
);
It looks like I didn't allow for that when I put together the Generic
driver. The method you provide is only given the credentials and not the
authentication object, so you are kind of out of luck with that.
You have a couple of options:
1. Configure the app at run time in a prerun or something like that:
__PACKAGE__-add_callback('prerun', sub {
my $self = shift;
$self-authen-config(
DRIVER = [ 'Generic', sub { check_password($self, @_ ) } ],
);
});
2. Create your own Driver plugin that does things your way. It is actually
easier then you might think. Just copy the Generic driver class and change
the 'verify_credentials' method to suit your needs.
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] CGI::Application::Dispatch
On Wed, Feb 11, 2009 at 5:45 AM, Lyle webmas...@cosmicperl.com wrote: Hi All, I was just looking at this modules docs and I noticed it says:- 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 I'm guess it might have come up before, but might be worth mentioning anyway. If you are on Vanilla CGI, you can rename you index.cgi to just index, then use Apache config like:- Files index SetHandler cgi-script /Files To get URLs like:- yourdomain.com/index/run_mode There is another easier way to do this using the mod_negotiation module and the MultiViews option. Directory /var/www Options MultiViews /Directory This allows you to leave your script as index.cgi or foo.cgi or even foo.html. Then when you request /foo/index and /foo/index does not exist, apache will look for /foo/index.* and pick the most appropriate file it finds. This is also useful for sending out PNG files to browsers that can accept them, and GIF files to ones that don't. Just put both files in the same directory, and in your IMG tag leave off the extension. Apache will look at the incoming headers to pick the most appropriate file to send out (This has the potential to mess up reverse proxies, but you can add a Vary: User-Agent header to fix that at the cost of reducing your cache effectiveness). See the docs for more info: http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] OSDC
Just wondering if anyone on the list is going to be at OSDC Sydney this week. Drop me a note if you are. http://www.osdc.com.au/ Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] run mode issues when posting data
On Wed, Nov 26, 2008 at 4:32 AM, Michael De Soto [EMAIL PROTECTED] wrote:
The above works great for the the authentication aspect of my
application. Advice on the above would be great, but it's not the
primary reason I write now. Now I have trouble with a run mode called
edit_user. This simply displays a form pre-populated with user data if
the query string looks like: ?rm=edit_useruser_id=1, and displays a
blank from if the query string looks like: ?rm=edit_user. This is
simple enough.
The trouble comes when I try to submit that form. When submitted, the
parameters are passed and stored as they should be in
$app-param('query'), but the run mode that is fired is the default
run mode as specified in setup(). If I change POST to GET (and make no
other change) the app works as it should and edit_user is triggered
allowing the form to be posted back to itself. If I change the form
back to POST, we trigger the default run mode.
Are you perhaps mixing GET and POST parameters? Did you put an action
in your form tag, and also add the rm and user_id as hidden input
fields?
form method=POST action=my.cgi?rm=edit_useruser_id=1
...
/form
The above will not work, since the CGI.pm object will ignore the get
parameters in the URL and only look at the parameters in the POST
body.
form method=POST action=my.cgi?rm=edit_useruser_id=1
input type=hidden name=rm value=edit_user /
input type=hidden name=user_id value=1 /
...
/form
That will work, since all parameters are part of the post body.
You can edit the source code of CGI.pm to get it to parse both the GET
and POST params if they both exist, but I would not recommend that.
If you want to get a bit more advanced, you can use the PATH_INFO to
pass these values:
form method=POST action=my.cgi/edit_user/1
...
/form
That requires some more work in your application, but makes your forms
simpler and your URLs cleaner. Ask if you want more details.
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] suitability of Autorunmode
On Thu, Nov 20, 2008 at 5:50 AM, Richard Jones [EMAIL PROTECTED] wrote: See my earlier posting - CAP::AutoRunmode not working with mod_perl again ?? It's viewable here: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg07094.html If you *do* get it working with mod_perl, I would be very interested to hear about it. I can't. See also CAP::RunmodeDeclare as an alternative, which *does* work with mod_perl, at least in my setup. Hi Richard, I run AutoRunmode under mod_perl successfully, but I do remember having problems with it. If I remember correctly (and it's been a few years since I looked into it), I had to make sure that Attribute::Handlers was installed, and I had to load the plugin in my instance script as well as in the application. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Using CAP::Authentication with multiple scripts
On Sat, Aug 2, 2008 at 2:25 AM, Gurunandan R. Bhat [EMAIL PROTECTED] wrote: Hi, I am new to CGI::App and want to use CAP::Authentication. I have a couple of questions and would really appreciate some help: 1. I want to use CAP::Authentication::Driver::DBH. with my own custom run-mode that generates a login page. Is that OK? Yes you can do that. 2. In my custom login page, what should I submit to? You can submit it to any runmode in your application, because the authentication checks happen at the prerun level. If the user isn't authenticated, it will display your custom login page, and it can submit to the same runmode as long as the credentials (username and password) are also submitted. In the prerun stage, the credentials will be checked, and if it passes, it will just continue on to display the current runmode that you are submitting to. You can also provide a 'destination' parameter in the submitted form, which will cause it to redirect on success to the destination that was provided. 3. If I want to separate my application to different modules, should I have a separate login runmode in each module. Obviously not. So how do I organize my code to control login from a single point? You generally do that by creating a base class for your application that all your separate modules inherit from. You put the authentication info in the base class, so all subclasses will inherit the authentication info. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Application params problem
Hi Amelia,
Whenever someone has problems using a simple method like $self-param,
I immediately think of namespace collision. My guess is that you have
something like this in your CGI::Application module:
use CGI qw(:standard);
What that does is import a bunch of subroutines into your application,
and one of them is called 'param'. So when you call $self-param you
are not calling the param in CGI::Application, but the one in CGI.pm.
Hence -- All hell breaks loose.
It may not be CGI.pm causing the issue, as 'param' is a pretty common
subroutine name. But my guess is some module is polluting your
namespace.
Cheers,
Cees
On Fri, Jul 11, 2008 at 9:56 AM, Amelia Ireland
[EMAIL PROTECTED] wrote:
On 10 Jul 2008, at 15:50, David Baxter wrote:
Hi Amelia,
It looks like you are trying to set the CA params like query params and I
don't think that works. Try a different syntax :
$self-param('validated_query' = $valid_h);
I tried both $self-param('validated_query', $valid_h) and
$self-param('validated_query' = $valid_h), but neither works, although
according to the docs, both are valid methods of setting params [ see
http://search.cpan.org/~markstos/CGI-Application/lib/CGI/Application.pm#param()
].
In both cases, when I try to get the param value using
$self-param('validated_query'), it has been set to 'validated_query',
rather than $valid_h.
Hmmm...
--
Amelia Ireland
GO Editorial Office
http://www.ebi.ac.uk || http://www.berkeleybop.org
BBOP Plant Project: http://bbopgarden.blogspot.com
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Re: bug report: 'make test' fails when $HEADERS_ONCE of CGI.pm globals modified
On Tue, Jul 8, 2008 at 11:05 AM, Mark Stosberg [EMAIL PROTECTED] wrote: So, nope, not our problem. Thanks for the feedback. I went ahead and rejected the bug. I agree that it isn't really the responsibility of CGI::Application to account for these problems. But since this has caused a user some problems, I think it makes sense to put something in the test suite that at least notifies the user that their setup will not work properly with CGI::Application or at least it will not work properly with the test suite. I would leave the existing test as is so they do fail in this situation, but add an extra test that checks for the value of $CGI::HEADERS_ONCE, and if it is set, fail the test and display a warning message about why this could be an issue. We could check for $CGI::HEADERS_ONCE and skip the problem tests, but I think that would hide the underlying problem and potentially cause more issues for the user. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] the plugin CGI::Application::Plugin::Session issue
On Tue, Jun 10, 2008 at 5:31 PM, Mike. G [EMAIL PROTECTED] wrote:
Hi, list
I got one issue when I use the plugin CGI::Application::Plugin::Session
**SNIP**
COOKIE_PARAMS = {
-domain = $this-cfg('site_domain'),
-expires='+40m',
-path='/',
-secure=1,
},
);
**SNIP**
*when I refresh that script, we always got the difference session id, why?*
Hi Mike,
That is usually due to a cookie problem. Make sure the cookie is
actually being set in the browser, and that it is being returned back
to on the next request. The Live HTTP Headers plugin for firefox is
really handy for this.
If the cookie isn't being set, then I would remove some of the cookie
options that you have set above. Start without any cookie options and
then start adding them in until you find the problem.
There is another problem that can sometimes cause this. CGI::Session
sometimes has issues flushing the session to the database unless it is
done explicitly. I believe the main cause of this is the database
handle going away before CGI::Session has a chance to flush it to the
database. Adding a call to flush the session in the teardown stage
usually solves that. Just add the following to your base class:
__PACKAGE__-add_callback('teardown', sub {
my $self = shift;
$self-session-flush;
});
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Q: Any guidelines for paging thru db records via CGI params?
On Mon, May 26, 2008 at 1:36 PM, Ron Savage [EMAIL PROTECTED] wrote: Hi Dan I like Data::Page::Navigation. Each link for selecting a page would include the search criteria including the page number. DBIx::Class offers I'm intending to use Data::Page. Hi Ron, If you are using Rose, then you don't need to bother with Data::Page. Rose provides convenience methods to do your limit/offset values. $products = Product::Manager-get_products( query = [ ... ], per_page = 10, page = 2, ); Then in your prev/next links just include the page number they are on, and optionally the number of items per page. a database agnostic syntax for limiting the rows returned to the page requested, so I guess Rose would too. Yes it does. The question is how to let the end user manage the transition from page to page. If it is a search result that you are displaying, then I usually just pass the original search parameters along with the page number in the prev and next links. The benefit of that is that you don't need to worry about sessions, or storing the search results. The potential drawback is that the search results could change from page to page if the data being searched changes rapidly (ie a new product may be added that matches the search criteria which will bump the search results around a bit). I don't worry about that too much though. I wrote a CGI::App plugin that does paging a few years ago, but I never released it. It manages all the URL generation for you, and all you have to do is give it the total number of search results. It gleans the other info (like page number) from the current query params, so it can properly highlight what page you are on. I use it with Rose::DB::Object and it makes life very easy. One drawback you might have on my solution is that it uses Template::Toolkit, and I believe you are still in the HTML::Template camp, so it may not be right for you. It could be made to work with HTML::Template though. I am willing to share if anyone is interested. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Variable Number of Column in a Table
On Fri, May 16, 2008 at 2:03 AM, Stephen Carville
[EMAIL PROTECTED] wrote:
Is there any way to have a template where the number of columns is
determined at run time? I know how to use TMPL_LOOP but that only
lets me vary the number of rows.
I realize that you are using HTML::Template, and you may be tied to it
for reasons good or bad, but
whenever I see people trying to bend a tool to do things against it's
will I feel obliged to show another way ;)
In my example below, the data is provided in a format that is easy to
generate using a DBI call, and the template itself is pretty straight
forward. Row colouring is also made easy using the Cycle plugin (if
you want to alternate between three colours, just add another entry
into the cycle and leave the rest of the template as is).
use Template;
my $template = Template-new( POST_CHOMP = 1 );
my $data = {
headers = [qw(col1 col2 col3 col4)],
rows= [
[ qw(1.1 1.2 1.3 1.4) ],
[ qw(2.1 2.2 2.3 2.4) ],
[ qw(3.1 3.2 3.3 3.4) ],
[ qw(4.1 4.2 4.3 4.4) ],
[ qw(5.1 5.2 5.3 5.4) ],
[ qw(6.1 6.2 6.3 6.4) ],
],
};
$template-process(\*DATA, $data) or die $template-error;
__END__
[% USE rowclass = Cycle('oddclass', 'evenclass') %]
table
tr
[% FOREACH col IN headers %]
th[% col %]/th
[% END %]
/tr
[% FOREACH row IN rows %]
tr class=[% rowclass %]
[% FOREACH col IN row %]
td[% col %]/td
[% END %]
/tr
[% END %]
/table
Cheers,
Cees
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Test Failures with CGI::Application::Plugin::TT
Hi Michael, I knew about these problems already because of the amazing CPAN testers. However, I was waiting for someone to pipe up that might help me in solving the problems :) The first two problems look to be cosmetic issues in Template Toolkit (ie it is using the wrong path separator on windows). My guess is that this doesn't actually cause any problems, but we should be able to fix the test suite to account for it. Like you said, the third problem looks like it could be an issue (although it is only an issue with the new precompile feature, so upgrading on windows should still be safe if you avoid that new feature). I don't have a windows box to play with so there is not much I can do to fix this. I would appreciate if someone could take a few minutes to do some debugging. A patch would be greatly appreciated, and/or SVN access to my CAP::TT repo can be organized for anyone willing to put in a bit of time to fix this problem. Cheers, Cees On Wed, Mar 5, 2008 at 1:39 AM, Michael Lackhoff [EMAIL PROTECTED] wrote: Hello Cees, thanks for the new versions of your plugins. Everything looks fine with a tiny exception: t/09_precompile_dir..1/6 # Failed test 'file is cached' # at t/09_precompile_dir.t line 31. # got: 'C:\.cpan\build\CGI-Application-Plugin-TT- 1.04\t\include1\TestAppIncludePath/test_mode.tmpl' # expected: 'C:\.cpan\build\CGI-Application-Plugin-TT- 1.04\t\include1\TestAppIncludePath\test_mode.tmpl' # Failed test 'file is cached' # at t/09_precompile_dir.t line 31. # got: 'C:\.cpan\build\CGI-Application-Plugin-TT- 1.04\t\include1\TestAppIncludePath/test_mode.tmpl' # expected: 'C:\.cpan\build\CGI-Application-Plugin-TT- 1.04\t\include1\TestAppIncludePath\test_mode.tmpl' # Failed test 'file is cached' # at t/09_precompile_dir.t line 31. # got: undef # expected: 'C:\.cpan\build\CGI-Application-Plugin-TT- 1.04\t\include1\TestAppIncludePath\test_mode.tmpl' # Looks like you failed 3 tests of 6. t/09_precompile_dir.. Dubious, test returned 3 (wstat 768, 0x300) Failed 3/6 subtests It looks as if the first two are harmless (just one slash/backslash mixed up) but the third error looks like something is really going wrong. As you can guess from the C:\... everything is under Windows 2000, Perl is a self-compiled 5.8.8 with VC6 from the official sources (not Activestate). Any ideas? -Michael # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
On Sat, Feb 16, 2008 at 2:06 AM, Brian Edwards [EMAIL PROTECTED] wrote: BTW, can somebody tell me if I am correct in using: use CGI::Session (qw/-ip_match/); use CGI::Application::Plugin::Session; to require the remote host ip address to match the ip stored in the session? Yes, that should work. There are a couple of things to consider when using this though. First, if you are running under mod_perl or some other persistent environment, then all your apps will use the -ip_match switch as soon as it is loaded in one of them. This is because it is implemented using a global variable in the CGI::Session namespace. Second, there are some clients out there that may come from different IP addresses on every request if they are using a pool of proxy servers. So make sure you know your audience when using this option. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
On Sat, Feb 16, 2008 at 10:02 AM, Michael Peters [EMAIL PROTECTED] wrote: Third, if you ever have to scale your application so that's it's behind a reverse proxy (a very typical first stage when scaling) everything will break since everyone will appear to be coming from the same IP. For an apache solution to this problem, you can use mod_rpaf to solve the issue. Your proxy servers should be adding a Forwarded-For header with the IP address of the originating requester. If you run mod_rpaf on the servers behind the proxies, and tell it about all your proxy servers, then it will tell apache what the real originating address is, and all your apps will see that value. Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Anomaly in CAP::Session
On Sat, Feb 16, 2008 at 3:17 AM, Brad Cathey [EMAIL PROTECTED] wrote: I don't know if this has been discussed previously, but I can't kill a session with: $self-session_delete; however: my $session = new CGI::Session(); $session-delete(); works like a champ. Am I missing anything? That is odd, since if you look at the source you will see that the first thing that a call to session_delete does is call -delete on the session object. The rest of it is just dealing with cookies. How are you checking to see if the session is deleted? If you call $self-session again as a test to see if it was deleted, then that will just create a brand new session for you. You need to look in the session store to see if the session was deleted or not. If you are sure it is a problem, then I will need to see a self contained example that shows the problem before I can go any further (preferably using the test suite). Cheers, Cees # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Persistence
On Feb 5, 2008 10:59 PM, Mark Knoop [EMAIL PROTECTED] wrote: Hi I'm new to CGI::Application. Welcome I like the way it makes me organize the script but I guess I could do it in this way without CGI:Application so I just want to be sure I fully understand the benefits. Given that I am not running it under mod_perl at this stage is each instance request a completely seperate event or does CGI::Application somehow keep track of something between one user's calls to the same instance? No, CGI::Application by itself does not offer any persistance. Each request will create a new CGI::Application object. You can use mod_perl or FastCGI to make the code persistent, but it will still create a new CGI::Application object on each request. If not then does CGI::Application offer any other benefits than helping one to organize ones code better? If you look at the source code for CGI::Application you will see that it is not very big and not very complex. So yes you are correct in thinking that you can probably structure your code that way without using CGI::Application itself. The benefit in using it is that you are using a module that has been tried and tested over many years by thousands of people. These people all structure their apps in a very similar way (ie the CGI::Application way), which means you can benefit from several thing: Code re-use - many people have spent time building lots of extensions to CGI::Application that make life for a web developer much easier. By using CGI::Application as your base you can benefit from all this work (search CPAN for CGI::Application::Plugin to see what is publicly available). Lower your Technical Debt - Building your own application code structure and rebuilding your own version of all the plugins that are available means you have to maintain all that extra code. And the person that takes over your project in the future has to maintain and understand what you have built. Using well supported modules and best practices lowers your technical debt for the future. It also gives future maintainers a starting place to look for help and documentation. Help from your peers - this mailing list has many people that may be able to help you if you run into problems, but only if you use CGI::Application. Building it all yourself means you are less likely to find someone that can (or is willing to) help you. Ok... have made some progress. It seems I can use the CGI::Application::Plugin::Session for the persistence side of things. But still feel like I am missing a trick will persevere and see if things become clearer. So it looks like you have already found some of the plugins :) The Session plugin will allow you to maintain state variables across requests. So if all you want to do is store some info for a user between requests (like an authentication token, or maybe their language preference, etc...) then the Session plugin will definately do that for you. If you still feel you are missing something, then explain to us what you are trying to do, and what you are expecting an application framework like CGI::Application to do for you. Cheers, Cees Hek # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] How do you handle MS smart quotes?
On 10/18/07, Graham TerMarsch [EMAIL PROTECTED] wrote: I've run into an issue on one of the projects that I'm working on and thought that I'd ping the list to see how others are handling this... The app accepts form data from the user, runs it through Data::FormValidator to validate it, then stuffs it into our PostgreSQL database. We're expecting users are going to cut/paste from MS-Word and as a result we're going to have to deal with MS smart quotes. My issue started with a DB error from DBD::Pg telling me that the input had an invalid byte sequence for UTF-8 (the tables in Pg are all encoded as UTF-8). Googling around brought me several possible solutions, but I can't say that I've found one yet that actually -works-. What I'd like the solution to do is: a) provide me a means of encoding/marking the data so that I can insert it into our Pg database without it throwing an error, PostgreSQL will do the character conversion for you, as long as you tell it what character set you are submitting the data in. SET CLIENT_ENCODING TO 'WIN1256'; If you want to set this globally for your system, you can set the PGCLIENTENCODING environment variable. I set that in apache, so all my web apps by default use LATIN1 encoding. SetEnv PGCLIENTENCODING LATIN1 So if your database is set to store values in UTF-8, PostgreSQL will convert all input from latin1 to UTF-8 before it stores it in the DB. And when you retrieve results from the DB, it will convert the UTF-8 back to latin1 before it gives it back to you. See http://www.postgresql.org/docs/7.4/interactive/multibyte.html#AEN18394 Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Problem install CAP::Authentication
On 6/14/07, John Day [EMAIL PROTECTED] wrote: I have had this running successfully on another machine, but the client has moved server. When I try to install CAP::Authentication all the dependencies install OK, but I get this: t/50_driver_authensimpleskipped all skipped: Authen::Simple required for this test t/50_driver_dbi.ok 1/74DBD::SQLite::st execute failed: database schema has changed(1) at dbdimp.c line 421 at I believe that is a bug with SQLlite that has to do with prepare_cached and then changing the underlying database schema and using the same prepared statement again. So that is not really an issue for this plugin, and you can ignore the failures. There is supposed to be a fix for this in the latest version of SQLite , but I am not 100% if it has been released. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Problem with CAP::Authentication and mod_perl
On 6/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I have two CGI::Application apps running on the same server under mod_perl. The first app does not need any authentication and has been working just fine until I started development of the second application which uses CAP::Authentication and CAP::Session to login users. Now on the first application I get a login screen. Both of your handler subs load and use the same Appl module, and it looks like you have two different versions of this Appl module: my $app = Appl-new(); $app-run(); Under mod_perl all apps run in the same instance of the perl interpreter, so you can only have one package named Appl. You need to make sure they are uniquely named. Cheers, Cees Hek - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CA::Plugin::Session test failure
This is a bug with CGI.pm. Upgrade that and the tests should pass.
Cheers,
Cees
On 5/1/07, Sergej Zoubok [EMAIL PROTECTED] wrote:
Hi Folks,
While installing my favorite CA plugins to a new macbook pro I hit a
snag. CGI::Application::Plugin::Session is failing a number of tests
from a single test script. This seems to be the source of most of the
failures noted by CPAN Testers. I expect that Cees has enough on his
plate already. Has anyone else found a fix?
FYI: I'm running perl 5.8.6.
Thanks,
Sergej
Key test output
==
t/06_expiry...ok 3/16
# Failed test 'session cookie expiry set'
t/06_expiry...NOK 4# at t/06_expiry.t line 21.
# 'Set-Cookie:
CGISESSID=c45d8e1acb40bf27953463e4d0f75d62; path=/; expires=+3600s
# Date: Tue, 01 May 2007 20:58:35 GMT
# Content-Type: text/html; charset=ISO-8859-1
#
# session expiry: (3600)
# '
# doesn't match '(?-xism:expires=\w{3}, )'
t/06_expiry...ok 7/16
# Failed test 'session cookie expiry set'
# at t/06_expiry.t line 40.
# 'Set-Cookie:
CGISESSID=c45d8e1acb40bf27953463e4d0f75d62; path=/; expires=+3600s
# Date: Tue, 01 May 2007 20:58:35 GMT
t/06_expiry...NOK 8# Content-Type: text/html; charset=ISO-8859-1
#
# session expiry: (3600)
# '
# doesn't match '(?-xism:expires=\w{3}, )'
t/06_expiry...ok 13/16
t/06_expiry...NOK 14# Failed test 'session cookie expiry set'
# at t/06_expiry.t line 64.
# 'Set-Cookie:
CGISESSID=dd9b4ccffeda8c7408154655689e860d; path=/; expires=-31536000s
# Date: Tue, 01 May 2007 20:58:35 GMT
# Content-Type: text/html; charset=ISO-8859-1
#
# session expiry: (-31536000)
# '
# doesn't match '(?-xism:expires=\w{3}, )'
Use of uninitialized value in subtraction (-) at t/06_expiry.t line 69.
# Failed test 'Expiry should not change'
# at t/06_expiry.t line 69.
# got: undef
# expected: '-1'
t/06_expiry...ok 16/16# Looks like you failed 4 tests of 16.
t/06_expiry...dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 4, 8, 14-15
Failed 4/16 tests, 75.00% okay
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CA-Subclassing + CAP::Authentication
On 2/19/07, Alexander Becker [EMAIL PROTECTED] wrote: I tried to subclass one of my apps and use the CAP::Authentication in one of the subclasses. That doesn't work. Each time i try to authenticate for one of the subclass runmodes, i don't get in. The authentication don't seem fail, as no error message appears (as it does if you enter invalid usn/pwd). The form simply pops up again. The subclass authenticates as usual. Can you clarify the problem a little bit more? You mention that the subclass is having problems, but then finish with 'The subclass authenticates as usual'? Which one is having the problem? package My::MyAppSuperclass::MyAppSubclass; use strict; use warnings; use base qw/CGI::Application/; Shouldn't the subclass inherit from your super class? ie use base qw/My::MyAppSuperclass/; I don't think that alone will fix your problem, but I'd need you to clarify these things before I can figure out what is going wrong here. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CAP::Authentication Setup Help
On 2/17/07, Carlos Ramirez [EMAIL PROTECTED] wrote: My questions: 1. If I'm using an external login script (URL), do I have to configure a DRIVER and handle my own session? The Authentication module needs to know whether or not there was a successful login and what the name of the user is that logged in. There are two ways to do that. Do exactly what the Authen plugin expects by manually setting up the session the way it wants it to be, or write your own Store module that can figure out your own way of deciding whether a user is logged in. 2. Does the login have to set/create the sessions? That is probably the easiest way of doing it. When there is a successful login, the plugin makes the following call to the store: $store-save( username = $username, login_attempts = 0, last_login = $now, last_access = $now ); So in your login.cgi you could use the Store module directly, and just make the above call manually on this Store object. However, I have to ask why you are doing this? Why do you have an external login.cgi script that does not use the Authen plugin? That would only seem useful if you have an existing authentication scheme, or a centralized authentication system. If you have such a centralized login system, then it must have some way of leting an app know that a user is logged in, and what that user's name is. You could write a custom Store module that decodes this information which will then show the Authen plugin that you are logged in. But if you don't have such a system, then the easiest way to deal with this is for your login.cgi module to also use the Authen plugin so the Session or Cookie is created for you, and everything will work cleanly. And the easiest way to deal with this is to just add the Authen plugin configuration to a base class that all of your modules inherit from. That way all your modules share a common authentication scheme, and you don't have to worry about using the external 'login.cgi' script at all. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] HTML standards: do you use them?
On 2/15/07, Ron Savage [EMAIL PROTECTED] wrote: On Wed, 14 Feb 2007 13:44:40 -0500, Robert Hicks wrote: Hi Robert See http://www.grc.com/mainmenu.css for some comments on IE's butchery of standards. Be warned: There are whole web sites dedicated to this topic. E.g.: http://catb.org/~esr/html-hell.html I have many more such references... One of the best out there that I know of is quirksmode: http://www.quirksmode.org/ I don't use it myself, since our design team does all the fiddly bits. I just write simple HTML and they do all the CSS and styling. But I do try to create standards compliant HTML in my templates. It really isn't all that difficult with HTML, but keeping the CSS standard and working across all browsers requires some black magic... Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Dangerous CGI practice?
On 2/9/07, Robert Hicks [EMAIL PROTECTED] wrote: Is it dangerous to pass relative paths to things instead of full paths? For example within my web app I have logging and I tell it where to log by 'logs/logname.log' and not '/home/public/logs/logname.log'. I also have my personal lib as: I generally have a config variable that contains the base directory of my application. That means there is only one place where this needs to be configured. The danger with using relative paths is that you could use a module that doesn't play nice, and it could call chdir on you when you don't expect it. This is doubly dangerous when using mod_perl, because it could be an other application that changes the directory on you. 'use lib qw( lib/ );' Have a look at the FindBin::libs which does that for you. You could also look at the FindBin module to find out the full path to your script file and use that to build the paths to your files. But there are issues with using this under mod_perl as well (see the docs). Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How do I delete a session in C::A::P::Session?
On 1/25/07, Brad Cathey [EMAIL PROTECTED] wrote: Thank you Dan. I did all this and it worked, but it seems like it should all happen with one method instead of 3. Having It should work with one call to $self-session_delete. You should note that CGI::Session does not actually delete the session until the session object is destroyed. But really your session should go out of scope when your program finishes, so it still should have worked. Perhaps the call to session_delete should undef the session object after it calls $self-session-delete... If undefing the session object after you call $self-session_delete also does not work, can you create a small self-contained test that shows this is not working? $self-session-delete(); really work would be nice, and make the most semantic sense. That will only delete the session out of the session store, but since CGI::Session does not do any cookie management, it will not delete your cookie. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application::Displatch v2, and CGI uploadInfo wierdness
On 1/14/07, Dan Horne [EMAIL PROTECTED] wrote: Hi I have an application that runs fine with CGI::Application::Dispatch v1. However, when I upgrade to CGI::Application::Displatch v2, my file upload code fails as CGI's uploadInfo is empty. There were several upload related problems in CGI.pm in the last several releases. What version of CGI.pm are you running? http://search.cpan.org/src/LDS/CGI.pm-3.25/Changes I know you mentioned that downgrading C::A::Dispatch fixed things, but it seems odd that C::A::Dispatch could affect uploads since it never touches the POST data... Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Authentication that remembers original runmode?
On 12/29/06, Mark Rajcok [EMAIL PROTECTED] wrote: I'm using CGI::Application::Plugin::Authentication and I'd like to have the application remember what runmode a user was trying to access if authentication is needed. For example, a user clicks on a link to 'page7' (or page6), but page7/page6 requires authentication, so the login page displays, but after the user logs in, I want page7/page6 to display. Hi Mark, By default, that is what should be happening. The provided login page includes a hidden field called 'destination' which is set to the original URL that was called. On successful authentication, an external redirect is called with that URL, which should bring the user to the correct page that they were originally trying to access. If you provided the POST_LOGIN_RUNMODE or POST_LOGIN_URL config options, then those would take presidence. If you have provided your own login box, then make sure that you manually set the 'destination' parameter in the login form. The rest should happen automatically. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: Thumbnail Image Server
On 11/30/06, Jesse Erlbaum [EMAIL PROTECTED] wrote: Hi All -- I'm working on a CGI-App based module for CPAN, and I'm looking for feedback in three areas: 1. Is there anything similar? Hey Jesse, I wrote a plugin for Template Toolkit last year sometime that does something similar. Not what you are looking for, but definately in the same vein. It works like this: [% USE image = Image::Thumbnail(root='/var/www' name='/images/foo.gif' width=100) %] [% image.tag %] The output would be something like this: img src=/images/foo.gif width=100 height=120 / or with more control: img src=[% image.name %] width=[% image.width %] height=[% image.height %] / Which outputs the exact same thing. Thumbnails are generated on the first request, and then saved in a cache keyed by the parameters that were passed in. What I like about this system is that it gives the power back to the designers (which is exactly what you are trying to do with the image server). 2. Is this useful / what features would make it more useful to you? Definately 3. What should it be called? That is always the most dificult part ;) If anyone is interested, my mailing list post regarding this is here: http://www.template-toolkit.org/pipermail/templates/2005-August/007765.html And the code can be found here: http://cees.crtconsulting.ca/perl/modules/Template-Plugin-Image-Thumbnail-0.01/ http://cees.crtconsulting.ca/perl/modules/Template-Plugin-Image-Thumbnail-0.01.tar.gz I never did upload it to CPAN, but I still use it in several big projects. I should probably throw it up there since someone might find it useful. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Plugin-DBH questions
On 11/16/06, Dan Horne [EMAIL PROTECTED] wrote:
On Wed, 2006-11-15 at 21:51 -0500, Chris Beck wrote:
If I don't want lazy-loading should I just create my own DBH? (I want to die
as
soon as possible if the DB connection isn't working)
My guess is this case is that the plugin isn't giving you any value, and
you may as well create the handle yourself in the init phase:
my $dbh = DBI-connect($dsn,$user,$pass) || _do_db_dead(DBI:errstr);
$self-param('dbh', $dbh);
and then when you need the database handle in your run modes
my $dbh = $self-param('dbh');
.. carry on coding...
The plugin can still give some value by doing things in a standard way
that will not surprise others when they come across your code. It
also may help with the use of other plugins. For example, the
Authentication plugin has a database driver that will default to
calling $self-dbh if it needs a database handle and none was provided
in the configuration.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CAF methodology
On 11/10/06, Mike Friedman [EMAIL PROTECTED] wrote: With Template Toolkit, if you pass your $self object to the template, then you can just say: [% self.some_other_run_mode %] And if you use the CAP::TT plugin, that is automatically done for you, except the variable is called 'c'. [% c.some_other_run_mode %] I am a little leery of calling runmodes like this though. Often runmodes will have side effects (like updating databases, or manipulating data somewhere). I try to keep that stuff out of my templates. Also, by calling a separate runmode, you will most likely be invoking your templating object again, and rendering an entirely new template. That can have performance implications. If I wanted to include the same snippet of info on a page, I would probably just call an INCLUDE file or MACRO from with in my template. If this needed some extra data, then I would probably have provided that data through the tt_params or tt_pre_process methods. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Plain CGI - FastCGI
On 10/27/06, Robert Hicks [EMAIL PROTECTED] wrote: Do I need to do anything to my CA web application to make it run under FCGI instead of CGI? I have the FastCGI DLL loaded in my Apache instance and I have registered .fgci to be served by it. Can I just rename my index.cgi to index.fcgi and away I go? I am just curious to see if FCGI will speed anything up. I can do mod_perl so now I want to play with FCGI for a bit. Have a look at CGI::Application::FastCGI, which should make this transition very easy. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Problems upgrading CA + Plugins
On 10/22/06, James Abbott [EMAIL PROTECTED] wrote: Hi Folks, I'm just revisiting an old C::A based app to add some new goodies, and as part of this set about upgrading the underlying C::A modules, since they've remained static since the site went live. I installed new versions of C::A with CAP::Apache, CAP::DBH and CAP::Session into my development tree, rather than the system perl libs, which are being used by the 'live' version of the app, and added an appropriate 'use lib' to my startup.pl (called from httpd.conf). A few debug statements have shown that the newly installed versions are being used in preference to the old modules. All is not well thoughhitting the apps launch page using the new modules gives me: [Sun Oct 22 09:20:57 2006] [error] Error executing class callback in init stage: Can't locate object method cookie via package Apache::Request at [trimmed]/CGI/Application/Plugin/Session.pm line 41.\n That error is occuring because CAP::Session is expecting an object that provides a 'param' method and a 'cookie' method much like CGI.pm does. However, Apache::Request only provides the 'param' method and makes you handle cookies in a different way. A simple solution is to use the CGI::Application::Plugin::Apache::Request module as your query object. This is a simple wrapper around Apache::Request which provides an API that is similar to CGI.pm and hence should work properly with CAP::Session. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Using AJAX with C::A
On 10/20/06, RA Jones [EMAIL PROTECTED] wrote: A sense of deja vu here from many years ago when encountering Perl for the first time! It only really began to make sense when I was able to take a working example and de-construct it line-by-line in my own working environment, and I think the same will apply to AJAX. A working example of a simple web app built around CGI::Application using AJAX would be most helpful. I did a talk on AJAX and perl at YAPC Chicago [1] this year. The slides for most of the talks are online [2], and I added links to my slides [3] and source code [4]. The slides for my talk are probably pretty vague without me talking around them, but the source code includes several working examples (some of which even use CGI::Application). I didn't use CGI::Application for all the examples, because the perl side of things was't usually the important bit, and using lots of perl modules may have required more explaining then I wanted to do. That having been said, there is some nasty CGI.pm html generation in some of the examples :) I like it for quick and dirty example scripts... If you really just want to see how the most basic AJAX request works, then look at the XMLHttpRequest example in examples/XMLHttpRequest. The first example (index.html) in there uses no extra JavaScript modules, it does everything manually. index2.html simplifies this by using the prototype.js library, and then index3.html simplifies things again by using JSON instead of XML with the prototype.js library. If you have any questions about any of the examples, let me know and I'll try and help out. Also note that I used prototype.js because it was popular, and easy to create some funky examples. There are many other really cool JavaScript libraries out there, and as others on the list seem to be doing, I am experimenting with JQuery, which looks very promising. Cheers, Cees [1] http://yapcchicago.org [2] http://yapcchicago.org/wiki/index.cgi?YAPCSlides [3] http://cees.crtconsulting.ca/perl/talks/yapc_ajax_and_perl/slides/start.html [4] http://cees.crtconsulting.ca/perl/talks/downloads/yapc_ajax_and_perl.tar.gz - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application article published on Perl.com
On 10/20/06, Mark Stosberg [EMAIL PROTECTED] wrote: A new CGI::Application article has been published on Perl.com today: http://www.perl.com/pub/a/2006/10/19/cgi_application.html Thanks to all of you who contributed plugins used in the article! Excellent article Mark. Reads very well, and covers a lot of ground. Should be useful to a lot of people. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] ValidateRM implementation question
On 10/14/06, Evan A. Zacks [EMAIL PROTECTED] wrote: But in the case of ValidateRM, the dfv_error_page() method is exported by default, so there shouldn't be a case where you can't call that method on $self. I think this may be a remanant of older versions of the code. In version 1.22 the recommended way to load the plugin was like this: use CGI::Application::Plugin::ValidateRM (qw/check_rm/); Is this calling style: some_method($self) a standard convention to use to protect against the case where some_method() may not be available to the calling class? I wouldn't call it standard, but more a method of last resort (no pun intended). What you end up doing here is making it difficult (if not imposible) to inherit and override this method. In other words, it is a hack that helps out in some instances, but should be avoided if at all possible. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Problem with CAP::Authentication/CGI::App::Dispatch, and redirects
On 9/29/06, Graham TerMarsch [EMAIL PROTECTED] wrote: I'm using CAP::Authentication in an app right now, along with CGI::Application::Dispatch, all running under mod_perl2. What happens is that any time that CAP::Authentication does a redirect, I get back 200 - OK HTTP response headers instead of 302 - Moved headers... This causes the unfortunate problem of showing a Document has moved 'here' page each time someone logs in/out, instead of doing the actual redirect. From digging a bit further into CAP::Authentication I see that the Location header gets set up properly when doing redirects, but the HTTP Status is --not-- set up. This looks like an oversight on my part. Thanks for reporting this. I have packaged up a new version which you can download here: http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin-Authentication-0.12.tar.gz Let me know if that fixes things for you, and I'll upload it to CPAN. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] multiple forms on a page and Plugin::ValidateRM?
On 9/26/06, George Hartzell [EMAIL PROTECTED] wrote:
George Hartzell writes:
I have a page that has several forms, each form has a hidden input
named rm which specifies a unique the runmode for the contents of
that form.
The runmodes use CAP::ValdateRM. When there's an error, it generates
an error page for me but files in *all* of the forms' rm input
variables with the value of the runmode that generated the error.
I understand why it's happening, but the resulting form doesn't do the
right thing if someone chooses one of the other submit buttons.
Anyone have any suggested work arounds?
I apologize for answering my own questions, but adding
{ ignore_fields = ['rm'] },
to the check_rm call seems to make it behave.
Does that seem like the right solution?
You should also be able to name your forms, and have HTML::FillInFOrm
(which is used under the covers by ValidateRM) only fill in the form
you are concerned about. This means all other forms on the page are
left as is.
See the docs for HTML::FillInForm for the right syntax.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application::Plugin::AnyTemplate vs. CAP::TT
I noticed that no one answered this question. I am not really the right one to answer it, since I use CAP::TT exclusively. Does anyone else have any comments? Cheers, Cees On 9/15/06, George Hartzell [EMAIL PROTECTED] wrote: I'm just getting started w/ CGI::Application, and am pretty excited. I'm using the Template Toolkit. It seems to me that it's a good idea to use CAP::AnyTemplate since that gives me the flexibility to change templating systems. I've noticed that several of the plugins (HTMLPrototype, DevPopup, MessageStack, others?) seem to do special things when working with the TT templates, but they all refer to CAP:TT. Will I loose their special functionality if I use AnyTemplate? Can I use both TT and AnyTemplate, then do my stuff in AnyTemplate and let the other libs use the TT interface? Is there something that the TT plugin does that the AnyTemplate couldn't be extended to do if someone added the necessary tuits? Thanks, g. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC - CGI::Application::Plugin::JSON
On 9/18/06, Mike Friedman [EMAIL PROTECTED] wrote: Recently there's been some chatter on the DBIC list (not sure if you're subscribed there) about a JSON serializer for DB data. Thought you might find it interesting from an integration perspective. http://lists.rawmode.org/pipermail/dbix-class/2006-September/002442.html For those who use (or are interested in) Rose::DB::Object, json has been supported for quite a while already through the Rose::DB::Object::Helpers module. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Co-operation of LOGIN_SESSION_TIMEOUT - IDLE_FOR in CAP::Authentication and the _SESSION_ETIME in the session?
On 8/10/06, Anthony Chee [EMAIL PROTECTED] wrote: I would like to ask how the two parameters mentioned co-operate together. Are they overlapped on the functionality? I tried to set IDLE_FOR is 30m and _SESSION_ETIME is 10m for the program. I discovered that I can still access the logged-in page after closing the browser, skipping the normal logout procedure, and accessing the system again. Is it normal? How should I config the two parameters if I want to ignore the old session when accessing the system again after closing the browser? There is no way for the server to know that you closed your browser,and then started it up again. To guess that this happened we usually use 'browser session' cookies which have no fixed expiry set. That means that the browser is supposed to clear that cookie when the browser closes, but to keep it for ever if the browser stays open. So when you set an expiry on your CAP::Session, the cookie gets an expiry time, which means it does not act as a 'browser session' cookie, so when you close the browser, the cookie gets saved to disk, and the next time you open your browser, the cookie is loaded back in (unless the exiry time has passed). So if you set an expiry on your CAP::Session closing the browser does nothing. The IDLE_FOR parameter sets an expiry on one of the parameters in your CAP::Session. It basically tells it that this parameter is only good for 10 minutes. But on every request, it resets that timeout, since the user is not idle and has another 10 minutes to go. So I guess what you want is to remove any expiry on the CAP::Session configuration, and just use the expiries in the Authen configuration. Let me know if that works for you. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CAP::Authentication
On 7/21/06, Anthony Chee [EMAIL PROTECTED] wrote: Hi Cees Hek, I would like to know what initialize for. In my knowledge it is used to start the authentication. I got some confuse when there is no initialize in the sample.cgi. 'initialize' is called automatically for you. You should never need to call it directly. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Plugin TT - Changing Options
On 7/20/06, Jeff MacDonald [EMAIL PROTECTED] wrote: So, what I'm trying to do is : 1: turn off my PRE/POST processing and parse an email template and send it out to the user. 2: turn the PRE/POST back to what they were and forward the runmode along. Here's whats actually happening. 1: The mail get's sent as I would expect, without the PRE/POST processing. 2: When the run mode get's forwarded, signup_complete renders without the PRE / POST processing. Idea's ? The TT object is only created once, and is then cached for the duration of the cgiapp object (if you configured it with $self-tt_config), or for the duration of the process (if you configured it with __PACKAGE__-tt_config). So changing the configuration in between calls to tt_process will do nothing, since the second call will just use the prevously created TT object. My guess is that you use the PRE/POST hooks to add a common header and footer to your pages (I use the WRAPPER config option for the same thing). However, my wrapper template has some extra logic in it that checks to see if a 'no_wrapper' variable has been set, and will not output anything if it is true. Here is what my wrapper.tmpl file looks like: [% IF no_wrapper %] [% content %] [% ELSE %] !-- start header -- [% PROCESS header.tmpl %] !-- end header -- [% content %] !-- start footer -- [% PROCESS footer.tmpl %] !-- end footer -- [% END %] So when I want to process a template that should not have the common header and footer, I pass in a no_wrapper parameter to my template and set it to 1. Another way to do the same thing is by changing the template include path. You can unshift an extra path to the front of your include path that contains an empty version of your PRE and POST templates. Those empty files will then override your regular files. If you are doing something different. let me know, but generally you can do what you need with a simple test in the template, instead of creating a new TT object with a new config. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CAP::Authentication
On 7/20/06, Anthony Chee [EMAIL PROTECTED] wrote:
Hi,
I would like to know whether there are more examples about
CAP::Authentication that on WWW. The page in CPAN contains very little
information. I do not know where should I put the methods in various run
modes, setup() or cgiapp_init(). Thanks.
You might try starting with the included example script that comes
with the distribtion. I should problaby mention in the docs that it
exists...
http://search.cpan.org/src/CEESHEK/CGI-Application-Plugin-Authentication-0.10/example/sample.cgi
This s a simple example, but it shows you how quickly you can get
setup with the Authentication plugin.
Generally most of the Authentication plugin calls can be placed in the
main part of your package, outside of any subroutines. In most cases
it will be only two calls that need to be made. One to configure, and
one to list which runmodes should require authentication:
SampleLogin-authen-config(%config);
SampleLogin-authen-protected_runmodes('two');
Those are straight from the included example script.
If you need more help (as it can get more complex if you want to
replace the login form with your own, or other such things), just send
another mail with your questions. I am on holidays until the start of
next week, so you may not here from me (but others may be able to help
as well).
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] trouble with 4.07_01, with smoke environment or with my code?
On 7/6/06, Gabor Szabo [EMAIL PROTECTED] wrote: In the test report of CGI::FileManager http://www.nntp.perl.org/group/perl.cpan.testers/327049 there is the following section: [ERROR] [Wed Jul 5 22:29:38 2006] MAKE TEST failed: No such file or directory /usr/local/perl-5.8.5/bin/perl Build --makefile_env_macros 1 test t/00.load...Argument 4.07_01 isn't numeric in subroutine entry at /usr/local/perl-5.8.5/lib/site_perl/5.8.5/CGI/Application/Plugin/Session.pm line 5. why? and who should fix that? Not sure why the smoke tester is using a development release... The line in the CGI::Application::Plugin::Session module is just loading CGI::Application to make sure that the correct version is being used: use CGI::Application 3.21; I am really not sure how you would go about fixing this. To me it looks like a problem with the smoke tester and their environment. They really shouldn't be testing your module while using experimental development releases of the modules you depend on... My guess is this problem will go away once CGI::Application 4.08 comes out. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: re-branding CGI::App
Let's call it møøse!!! Oh wait, that one is taken already. How about døtCGI!!! Nope, no good. How about Cøtølyst!!! This is tougher than I thought :) Seriously though, I think a cool name would be a good thing. But I generally come up with really crap names so I will leave it to others :-/ As long as the name CGI::Application continues to work, as there is a huge amount of mindshare there already with the existing userbase. A new name will really only appeal to new users and PHBs. Cheers, Cees On 7/6/06, Joel Gwynn [EMAIL PROTECTED] wrote: True. One should also consider google-ability. Web::Application could be as difficult to google as .NET. On 7/6/06, Gabor Szabo [EMAIL PROTECTED] wrote: Say aloud: So let's use Web::Application to build a web application. Very confusing. IMHO this is a bad choice for name. Gabor - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Class::MOP and performance
On 7/5/06, Perrin Harkins [EMAIL PROTECTED] wrote: On Mon, 2006-07-03 at 08:40 -0400, Ricardo SIGNES wrote: This is another good reason to work on making CGI::Application easier to use under mod_perl! Is there something difficult about using it under mod_perl? I think he is considering calling 'new' on a CGI::App object once, and then calling 'run' on it multiple times in a mod_perl environment. Currently that can lead to problems with leftover info in the object. However, the cost of creating a new CGI::App object is very minimal, so I don't think it is really a big problem at the moment. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Error during using CGI::Application::Plugin::Authentication
On 7/4/06, Anthony Chee [EMAIL PROTECTED] wrote:
$self-session_config(
CGI_SESSION_OPTIONS = [driver:file,
{
Directory = $self-param('serverRoot') . 'tmp',
}
],
DEFAULT_EXPIRY = '+10m',
);
**SNIP**
I got Error 500 when execute this module. And there is following error
in error.log
Error executing class callback in prerun stage: Failed to Create
CGI::Session object :: Reason: new(): failed: query object
HASH(0x154f72c) does not support cookie() and param() methods: Can't
call method cookie on unblessed reference at
C:/Perl/site/lib/CGI/Session.pm line 666.\n at
C:/Perl/site/lib/CGI/Application/Plugin/Authentication/Store/Session.pm
line 83\n
The problem is with your CAP::Session config. The second parameter
must be the session ID, or a query object.
CGI_SESSION_OPTIONS = [driver:file, $self-query,
{
Directory = $self-param('serverRoot') . 'tmp',
}
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::Plugin::Cache
of items that were removed from the cache. clear() $self-cache-clear; $self-cache( 'memcached' )-clear; Removes all objects from the specified cache. If no cache was specified, all objects are removed from the last active cache. object() $self-cache-object-some_cache_object_method( $arg1, $arg2, ...); $self-cache( 'disk' )-object-some_cache_object_method ( $arg1, $arg2, ...); Provides direct access to the underlying caching object. This method *should* only be rarely used - i.e., for circumstances where there is some functionality provided by the underlying caching mechanism that is not supported by the standard driver interface. Using object() bypasses many of the benefits provided by CGI::Application::Plugin::Cache, and as such, it's regular use is not endorsed. BUGS Please report any bugs or feature requests to [EMAIL PROTECTED], or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=CGI-Application- Plugin-C ache. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes. ACKNOWLEDGEMENTS A big thanks to Cees Hek for helping me transform my idea for a simple Cache::Cache plugin to a fully-featured generic caching interface. And, as always, thanks to the usual crowd in #cgiapp on irc.perl.org for keeping me company and making these projects worthwhile. SEE ALSO CGI::Application, Cache::Cache, Cache::FastMmap, Cache::Memcached. AUTHOR Jason A. Crome, [EMAIL PROTECTED] COPYRIGHT LICENSE Copyright 2006 Jason A. Crome, all rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::Plugin::Cache
On 6/19/06, Jason A. Crome [EMAIL PROTECTED] wrote:
On Jun 19, 2006, at 12:45 PM, Graham TerMarsch wrote:
Oh, this sounds nice. :)) I'm regularly having to deal with needs
to caches
in various parts of our applications, but having something
integrate directly
with C-A would be -sweet-.
I am looking forward to seeing this as well!!
$self-cache(['memory','memcached'])-get( $key );
SNIP
$self-cache('*')-get( $key );
to query against all known caches, in no guaranteed order?
Again, great suggestions. I had long been struggling for a way to
specify what caches should be searched at config() time. You could
also expand this logic to set for which caches to set a value in. get
() could become a bit hairy though.
I think that for simplicity sake, doing a set or get without
specifying a named cache should automatically go to each of the
caches.
Remember that setting a value in a memory cache as well as a disk
cache is not necesarily a waste of resources, because the disk cache
is shared across multiple processes wheras the memory cache would be
limited to the current process (same goes for memory mapped files, and
memcached like setups which are also shared caches).
An alternate solution would be to allow the user to configure a
'default' cache (or list of caches). That could then also be used to
solve the ordering issue.
default = ['memory', 'memcached'],
Or if you want different values for get and set allow 'default' to be
overriden with these:
default_get = ['memory', 'memcached'],
default_set = ['memory'],
In the end, I suspect that the majority of users will just use a
single caching system. So it is important to remember to make the
common case easy.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Accepting 3rd party sessions and CAP::Session
On 6/16/06, RA Jones [EMAIL PROTECTED] wrote: Presumably this is not the correct way to handle new session id generation in CGI::Session. Is it even possible to force CGI::Session to use a pre-defined session id string in the first place? If CGI::Session can not load a session from the ID given, it throws it away and creates a new one (at least that is the way it looks from the source code). I am not sure why that is done, but that is the way it currently works. One way around this may be to write your own custom ID generator for CGI::Session, and have it look for an existing session ID somewhere and use that, or failing that generate the ID in the usual way. For help on that you are probably better off using the CGI::Session mailing list. This is not something that CAP::Session can do anything about. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Plugin::Authorization
On 6/16/06, Michael Petnuch [EMAIL PROTECTED] wrote:
Hey,
Either I have uncovered a bug in the Plugin::Authorization or I am
doing something still. This is how I am setting up Authorization in
the cgiapp_init function of my superclass of my CGI::Application:
That definately sounds like a bug to me. If you can, it would help if
you could create a small test file that recreates this problem.
Cheers,
Cees
# This appears first
$self-authorization('is_user')-config(
DRIVER = [
'DBI',
DBH = $dbh,
TABLES = [ 'author', 'article' ],
JOIN_ON = 'author.authorId = article.authorId',
CONSTRAINTS = {
'author.username'= '__USERNAME__',
'article.articleId' = '__PARAM_1__',
},
],
FORBIDDEN_RUNMODE = 'forbidden',
);
# Then directly after this follows
$self-authorization('is_clearence')-config(
DRIVER = [
'DBI',
DBH = $dbh,
TABLES = ['author'],
CONSTRAINTS = {
'author.username'= '__USERNAME__',
'author.clearence' = '__PARAM_1__',
},
],
FORBIDDEN_RUNMODE = 'forbidden',
);
Now things were not working as I expected them to, so I edited the
DBI (DBI.pm around line 297) driver to print out the sql.
This was my results:
By executing this command: $self-authorization('is_user')-authorize
($id);
SELECT count(*) FROM author WHERE author.clearence = ? AND
author.username = ?
However, I was expecting this:
SELECT count(*) FROM author, article WHERE author.authorId =
article.authorId AND author.username = ? AND article.articleId = ?
By executing this comment: $self-authorization('is_clearence')-
authorize($id);
SELECT count(*) FROM author WHERE author.clearence = ? AND
author.username = ?
For some reason they both are executing the same sql. I though by
using the named version of each I could have separate checks for each
one. Why am I overwrite the first one?
Thanks.
Michael Petnuch: developer and webmaster for petnuch.com
contact | [EMAIL PROTECTED] - 914-837-6463 | aim - mpetnuch
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Plugin::Authorization
On 6/16/06, Michael Petnuch [EMAIL PROTECTED] wrote:
Hey Cees,
I put up a test script on my website. Since I was using the DBI
driver I created a simple database to show the problem (just in case
its a problem with the DBI driver?). Anyway, included in the files
is a database dump. I am using MySQL 5 and the latest versions of
CGI::App and the Auth and Authz plugins. I put the files here:
http://www.petnuch.com/TEST_FOR_CEES/
Thanks Michael,
That helped a lot. This is definately a bug, and since it is an
annoying one, I have packaged up a new release and sent it up to CPAN.
If you want it early, you can download it from my website here:
http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin-Authorization-0.05.tar.gz
P.S. I hope this is what you wanted, because I am not really familiar
with the Perl test modules to create an example using one of those.
What you provided was perfect. It saved me a lot of time, and hence I
was able to fix the problem quickly. As for using the perl test
modules, I'll show you very quickly how I altered your script to use
the tests:
# Added this to the top of the Testing.pm file
use Test::More qw(no_plan);
# testing a positive result
ok($self-authorization('is_user')-authorize(1), User is authorized
to edit article 1);
# testing a negative result
ok( ! $self-authorization('is_user')-authorize(2), User is not
authorized to edit article 2);
This ends up printing the results to STDOUT instead of collecting them
in $html, but I am not too worried about that, because I ran these
tests from the command line anyway. Doing it this way makes it
immediately obvious when something is wrong, and when you have fixed
it. Here is the failure results:
ok 1 - User is authorized to edit article 1
ok 2 - User is not authorized to edit article 2
ok 3 - User is authorized to edit article 3
ok 4 - User has clearence 1
ok 5 - User does not have clearence 2
not ok 6 - User does not have clearence 3
# Failed test 'User does not have clearence 3'
# in Testing.pm at line 110.
And once I fixed the problem, this is the result:
ok 1 - User is authorized to edit article 1
ok 2 - User is not authorized to edit article 2I get lots of info to
help in debugging.
ok 3 - User is authorized to edit article 3
ok 4 - User has clearence 1
ok 5 - User does not have clearence 2
ok 6 - User does not have clearence 3
So just by using that very simple 'ok' function, I can very quickly
see what is going on.
Thanks again for the bug report...
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Can't call method param on an undefined value...
On 6/15/06, Chico [EMAIL PROTECTED] wrote:
#create the variable to make the connection to the SQL
server, so whenever you need to connect you call the
$dbh variable
my $dbh =
DBI-connectDBI:mysql:database=gns_workflow;host=localhost,'root',
'MySQL!') or die didnt connect to the database;
#putting the $dbh into the $self object, that way you
can call $dbh anywhere in the program by issuing the
command $self-param('dbh')
my $self-param('dbh' = $dbh) or die couldnt
associate dbh variable to self;
You need to remove the 'my' keyword from that last line:
$self-param('dbh' = $dbh) or die couldnt associate dbh variable to self;
'my' is used to declare a variable (as a lexical variable), however,
$self is already declared at the top of your subroutine.
Attached is the entire program... Please take a look
and advise on any improvements. I am just learning so
take it easy on me ;0)
I'll give a few suggestions below to make your life easier. You are
re-inventing a lot of wheels that many others have already built.
package Portal::Application_2;
use base 'CGI::Application';
use CGI::Session();
If you plan to use CGI::Session, have a look at the
CGI::Application::Plugin::Session module, which makes it much easier
to use.
use DBI;
The same goes for CGI::Application::Plugin::DBH.
use strict;
sub cgiapp_init
{
my $self=shift;
#cgi::application uses the cgi.pm module. $self-_query() is equal to
$q=CGI-new()
my $q=$self-query();
The above two plugins use the same philosophy as the -query method.
They allow you to call $self-session to get a CGI::Session object, or
$self-dbh to get an active database handle.
#create the variable to make the connection to the SQL server, so
whenever you need to connect you call the $dbh variable
my $dbh = DBI-connect(DBI:mysql:database=gns_workflow;host=localhost,'root',
'MySQL!') or die didnt connect to the database;
#putting the $dbh into the $self object, that way you can call $dbh
anywhere in the program by issuing the command $self-param('dbh')
my $self-param('dbh' = $dbh) or die couldnt associate dbh variable to
self;
my $data_source = DBI:mysql:database=gns_workflow;host=localhost;
my $username = 'root';
my $password = 'MySQL!';
$self-dbh_config($data_source, $username, $password);
# now you can call $self-dbh to get your database handle.
# Initialize the session and get the id.
my $session = CGI::Session-new
(
'driver:MySQL',
$q-cookie('CGISESSID') || $q-param('CGISESSID') || undef,
{
Handle=$dbh,
LockHandle=$dbh
}
)or die couldn't establish session;
#sets the expire time for the session. It only expires after that
amount of time after inactivity. Every time the user does something the expire
time is reset.
$session-expire(10m);
#put the session id into the $sessionid variable
my $sessionid = $session-id();
# Put session id and into $self object
$self-param('sessionid'=$sessionid);
# Put session into $self object
$self-param('session'=$session);
# replace the above with this
$self-session_config(
CGI_SESSION_OPTIONS = [ driver:MySQL, $self-query,
{Handle=$self-dbh} ],
DEFAULT_EXPIRY = '10m',
);
# now you can call $self-session to get a CGI::Session object when
you need it. It will handle sending the cookies for you, and will
automatically load the correct session for each request.
login_form;
This isn't the right place to be calling 'login_form'. If you want to
handle logins, you can use another plugin called
CGI::Application::Plugin::Authentication.
}
#when using CGI::Applicaiton you need to define the basics of your application.
For example, what the rum modes are, and which run mode that should be started
in first.
sub setup
{
#Here we are getting the object. Think of it as a box that is passed
around from one person to another, you can put stuff in and take stuff out of
the box.
#We have just accepted the box by typing $self=shift;.
#The shift function removes the first value of the specified array.
If you dont specify an array the function shifts @ARGV (in the main program), or @_ (in
subroutines)
#Since we didnt specify an array, and are in a subroutine we are
grabbing the @_
#Within a subroutine the array @_ contains the parameters passed to
that subroutine, and is considered a special variable
my $self = shift;
#cgi::application is based on the idea that everything a web
application does is a mode. Basically what this breaks down to is a mode is
simply associated with a subroutine.
# I find it simpler to just use the subroutine name for both the mode name
and the subroutine, however the directions show ('mode1' =
Re: [cgiapp] Problems with CGI::Application::Plugin::Authentication V 0.10
On 6/9/06, Ron Savage [EMAIL PROTECTED] wrote:
Hi Cees
(1)
Here's how I'm calling CAP::Authentication in my cgiapp_init():
$self - authen() - config
(
CREDENTIALS = [qw/username password/],
DRIVER =
[
'DBI',
CONSTRAINTS =
{
'staff.username'=
'__CREDENTIAL_1__',
'sha1:staff.password' = '__CREDENTIAL_2__',
},
DBH = $self - param('dbh'),
TABLE = 'staff',
],
POST_LOGIN_RUNMODE = 'display',
STORE = 'Session',
);
$self - authen() - protected_runmodes(':all');
Looks reasonable
(2)
When my app starts, I get this msg in Apache's error.log file:
[Fri Jun 09 15:07:07 2006] [error] [client 127.0.0.1] Color::Calc is required
when specifying a custom BASE_COLOUR, and leaving LIGHTER_COLOUR, LIGHT_COLOUR,
DARK_COLOUR or DARKER_COLOUR blank or when providing percentage based colour at
d:/Perl/site/lib/CGI/Application/Plugin/Authentication.pm line 1357., referer:
http://127.0.0.1/cgi-bin/menu.cgi
I'm not explicitly using color in any way, so I'm getting the warning /by
default/!
Bug. Fixed in latest version
(3)
You module displays a nice log in form, which I fill in.
After I click your Sign in button, my app's first screen appears.
Then when I click a submit button, the app dies with:
[Fri Jun 09 15:08:18 2006] [error] [client 127.0.0.1] Error executing run mode
'authen_login': Undefined subroutine CGI::start_html called at
d:/Perl/site/lib/CGI/Application/Plugin/Authentication.pm line 1641.\r, referer:
http://127.0.0.1/cgi-bin/aussi/aussi.cgi
Now lines 1641 to 1645 are:
$html = join( \n,
CGI::start_html( -title = $login_options-{TITLE} || 'Sign In' ),
$authen-login_box,
CGI::end_html(),
);
Another small bug. I should have explicitly use'd CGI.pm. I'll
refactor the dependancy on CGI.pm out at some point but for the next
version I will just add 'use CGI ();' (patches welcome)
So there several problems here:
(a) Why is it calling this code? I ought to be logged in, but there's nothing in
the sessions table to indicate that I am
It should have caused a problem on the first load as well. If you saw
the builtin login box, then it ran that bit of code, and hence CGI.pm
must have been loaded for that request.
(b) You don't do use or require CGI. Yes, I do have it installed :-).
fixed now. see above comments.
(c) I don't /want/ to use CGI. I use CGI::Simple as in:
Which should be fine.
so methinks your CGI code should have tried something like $cgiapp - query() -
start_html().
That would not work with CGI::Simple, though :-).
right. So for now I am explicitly loading CGI.pm, but will get rid of
it completely in the future as I was just too lazy to write out the
HTML myself (I only use CGI.pm for the start_html and end_html methods
which really is a waste if you don't normally use CGI.pm).
(4)
I certainly do have time available to help debug your module, but it's 3:30 pm
on a Friday here now...
And I am a little bit late answering... But in a couple of months
I'll be in your timezone so I might be a little more timely in my
responses ;-)
The fixes are in SVN, but since they are fairly minor, I may hold off
on a new release for the time being.
http://cgiapp.crtconsulting.ca/svn/cgi/application/plugin/authentication/trunk/
Thanks for the bug reports, and let me know if you run into any other problems.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Long running modes - how to display please wait?
On 5/29/06, James.Q.L [EMAIL PROTECTED] wrote: --- Mark Stosberg [EMAIL PROTECTED] wrote: One pattern to address this was proposed by Randal Schwartz in 1997: http://www.stonehenge.com/merlyn/WebTechniques/col20.html Simplified: Fork the long running process into the background. This process can report its status to a file as it goes. The page that the user sees can refresh it periodically, checking the status via the file and reporting back to the user. I've used this kind of pattern successfully myself. haven't used mod_perl much. i am curious if it works well under mod_perl ? Although forking mod_perl works fine, you are generally discouraged from forking a mod_perl process, since you are forking a very large process (the entire apache child process with mod_perl can be quite large)). What I usually do in that case is setup a job queue (on the file system or in a database). The web process writes some information about a new job into the queue, and then there is a separate daemon process (or cronjob) that checks intermittantly for new work in the job queue, and runs the jobs. You effectively get the same results, without having to fork your web app. You only incure a slight delay for processing to start until the daemon process checks for new work. Your result page can refresh for updates just like in the forking process. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Replacing CAP::Plugin::Authentication login_box
On 4/29/06, Ed Pigg [EMAIL PROTECTED] wrote:
If I want to replace the built-in login form I need a method that
will generate the html form correct? So in my base class do I create
sub login_box {
}
or do I create a separate login sub.
Looks like I am probably a little bit late for this one. Sorry!
What you can do is create a runmode that generates a login HTML page.
Then just set the LOGIN_RUNMODE config parameter to tell the Authen
plugin to redirect to that runmode when a login is required. You can
also provide an external URL through LOGIN_URL, which could be used to
send a user to a central authentication website.
Before you try that though, have a look at the latest version of the
Authen plugin which I uploaded last week. I have made the login box
much more configurable, so hopefully you will not have to create your
own custom one. You should be able to make it look however you like
by changing the stylesheet. Or if you just want to change the colour,
that is really easy now.
If you find you still need to create your own custom login box, let me
know why, and I'll see if I can make some more customizations.
Cheers and sorry for the late reply,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Replacing CAP::Plugin::Authentication login_box
On 5/23/06, Ed Pigg [EMAIL PROTECTED] wrote: On May 23, 2006, at 8:39 PM, Cees Hek wrote: What you can do is create a runmode that generates a login HTML page. Then just set the LOGIN_RUNMODE config parameter to tell the Authen plugin to redirect to that runmode when a login is required. You can also provide an external URL through LOGIN_URL, which could be used to send a user to a central authentication website. Will that work if you are protecting all runmodes? You know, chicken/ egg sort of thing? You want to protect all, but you need the LOGIN_RUNMODE to log in, but all runmodes are protected, but you. I think the login runmode would have to remain unprotected... But I haven't tested it. The code just sets the prerun_mode to the new login runmode, so it may actually work. Your best bet is to just test it. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Help with CGI::Application::Plugin::HTMLPrototype
On 5/22/06, Robert Hicks [EMAIL PROTECTED] wrote: In looking at your source there (cool by the way) a question came to mind. The template is stored in the __DATA__ section. Is that your standard practice? Is it only because it is one page/template or does the Ajax integration need it that way? It is definitely not my standard practice. I do it that way in example scripts sometimes so that all the information is in one location, and since this is an example for a programmer, it is easiest to just include the template in the __DATA__ section. I find it makes it easier to follow the example without having to jump around different files. You may notice that in some of the examples I also use the CGI.pm library to generate HTML for me. This is also not something I often do, except in example scripts. I can write them fairly quickly that way, and it keeps the template stuff out of the way, when it is not important for the example. (and I loathe putting HTML directly in the perl code, so using the CGI.pm library makes me feel a little bit better about sticking HTML in my code ;) ) If I built all the example scripts the way I usually build my applications, then the actual idea I am trying to show/explain would have a tendency to get lost in the noise. You would end up with an instance script, a base CGIApp module, the real CGIApp module, a header and footer to wrap my templates, the actual template, etc... Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application::Plugin::Authentication. How to log a user in after prerun?
On 5/22/06, Simon Rees [EMAIL PROTECTED] wrote:
I'm using CGI::Application::Plugin::Authentication in my web application and
have found it useful but I'm stuck on a good way to implement some
functionality I need.
After a user has submitted their registration details I need to Authenticate
them straight away. The registration form contains a number of fields
including their chosen username and password which is submitted to a
CGI::App runmode where the data is validated and inserted into the
database.
The problem is that CGI::Application::Plugin::Authentication::initialize has
already been executed by the time this occurs.
Any ideas on how I could do this? I'm currently redirecting after processing
the registration data with the credentials in the query string - but I'm
not terribly comfortable with this solution...
You could call 'initialize' yourself after the user has signed up.
Then just make sure that the registration runmode is not protected (so
that the CAP::Authen prerun hook will not be executed, and any user
can try to register a new acount.
sub register {
my $self = shift;
# Do your normal registration stuff
$self-authen-initialize;
# redirect to your start page (using an external redirect)
}
I haven't tried that myself, but it should work. If you look in the
source for CAP::Authen, look for the 'prerun_callback' subroutine to
see what other things the prerun code does. You might also want to
set the last access time, or mark the this as a new login.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Help with CGI::Application::Plugin::HTMLPrototype
On 5/21/06, Prakash Inuganti -X (pinugant - Digital-X, Inc. at Cisco) [EMAIL PROTECTED] wrote: Yes, you are correct. Thanks. I already have a full blown Application developed using CAP and H::T. So using Template Toolkit right now is not an option for me. Now I am adding a page that has a select box with 60,000+ names stored in Oracle database that needs to be shown as dropdown options. So started looking at these Modules and AJAX. My idea is to provide a text field and a button. After user enters a few characters and clicks the button, I intend to populate the select drop down with names matching the text field entry. I am still at a learning phase so any ideas or sample code to accomplish this in CAP and H:;T would be a great help. You should look at using the AutoComplete object in HTML::Prototype. It will do exactly what you are trying to do, with minimal fuss. I have an example app running that uses this feature if you want to have a look at how I did it: http://cees.crtconsulting.ca/perl/examples/podviewer/ In fact, a version of that example is included with the source for CGI::Application::Plugin::HTMLPrototype. Although my example uses Template Toolkit. You can try and get it to work with HTML::Template, but if that fails, you can always just use the JavaScript library directly. Just run my example code, and then do a view source in the browser to see the exact JavaScript code that the HTML::Prototype library generates for you. Then just copy and paste that into your templates. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Help with CGI::Application::Plugin::HTMLPrototype
On 5/21/06, Dan Horne [EMAIL PROTECTED] wrote: From: Cees Hek [mailto:[EMAIL PROTECTED] http://cees.crtconsulting.ca/perl/examples/podviewer/ That's nice, Cees. As with many people, my interest in Ajax has been aroused with all of the press it has been receiving, buI've never been clear about the best way to start (Should I use Prototype, or CGI::Ajax? How do I integrate with CGI::App? How much Javascript do I need to learn? etc). Do you have any other examples online that I can look at? Hi Dan, I gave a talk on Ajax and Perl to the Toronto and Waterloo Perl Mongers. I'll be giving a similar talk at YAPC this year in Chicago. The slides and examples for this are available from my subversion repository. You might need to make a couple of little changes to get the examples working, but it should give you some ideas. http://cgiapp.crtconsulting.ca/svn/other/cees/talks/ajax_and_perl/ I prefer to use a dedicated JavaScript library, and then just roll my own perl code. Responding to an AJAX call is no different than responding to a regular page request. You just don't return an entire HTML page, just a snippet instead. Or you send JSON formatted data, or XML, or plain text. How you retrieve and process that data on the server is no different than any other request. So I don't see the benefit of the CGI::Ajax module personally. HTML::Prototype is a good way to get yourself familiar with the prototype.js library with the scriptaculous extensions. But after using it a while, you will find youself writing the JavaScript yourself. In the end generating JavaScript code from Perl is going to limit what you can do. You have much more freedom using the prototype.js and scriptaculous.js libraries and writing the JavaScript to use them directly. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Help with CGI::Application::Plugin::HTMLPrototype
On 5/20/06, Prakash Inuganti -X (pinugant - Digital-X, Inc. at Cisco) [EMAIL PROTECTED] wrote: Hi Mark, I did not realize I had to install prototype and sciptaculous javascripts. DAH. I got this example working. Now on to the next experiment. You should only have to install HTML::Prototype, which includes the prototype and scriptaculous javascript libraries in the source. I finally got around to trying this and looked up your email for help. Wherever I put !-- tmpl_var c.prototype.define_javascript_functions -- declaration, GUI shows HTML::Prototype=HASH(0x101be00). I have no idea about what's happening. I had to install quite a few dependent modules while installing CAP::HTMLPrototype and CAP::HTDot. Would this be because some module is not installed properly. Also when I click on 'Extra Info', I get a JavaScript error saying 'Effect is undefined'. Could you help me understand the issue please. I have never used the CAP::HTDot plugin, so I am not sure if CAP::HTMLPrototype works with it properly. However, it works wonderfully well with Template Toolkit and the CAP::TT plugin. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Site layout best practices question
On 5/19/06, Jesse Erlbaum [EMAIL PROTECTED] wrote: Now I'm starting to get ready for deployment and have turned on Taint mode with the -T option of the instance scripts and need to untaint the the environment variables. Is there a best practice for this? I generally don't use taint because I've found it to be a huge pain in the ass, with dubious security value. (It warns on many things which don't matter, and encourages the programmer to write bad regular expressions to hush up the warnings. If I wanted a language which forces me to jump through useless hoops, I'd use Java!) I don't tend to use Taint mode either. I rarely ever run system commands from web scripts, and when I do I always use the list method so as not to invoke the shell. When making database calls I always always always use placeholders. And when building filenames dynamically, I always strip out everything but alphanumerics and a couple other characters (like _ - and .). And lastly, I never use eval (unless absolutely necesary, and then never with user defined variables). These are pretty common rules that should always be followed regardless of whether Taint mode is on or off, and they protect you from most of the things that Taint mode is intended to help with. As for deailing with the ENV variables, it is easiest to just unset any ENV variables that you do not need. For things like PATH, just set it explicitly in your script. See the perlsec manual page for some examples of dealing with ENV variables under taint mode. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ 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::Plugin::Authentication 0.10
module: CGI::Application::Plugin::Authentication version: 0.10 A new version of the Authentication plugin went up on CPAN last night. This release aims to make it a lot easier to customize the default login page that is included with the plugin. You can now very easily change the colours that are used in the login box (can be as easy as providing one base colour and have all other colours automatically generated for you), or you can completely replace the stylesheet with your own. Or as a last resort, you can replace the entire login box with a completely custom version. It is also easier to embed the login box into another existing page as well. The other important change is that support for Authen::Simple was added. This means that you can use any of the Authen::Simple modules available on CPAN directly as a driver in CGI::Application::Plugin::Authentication. Following is a full list of Changes: 0.10 Thu May 18 22:59:56 EDT 2006 - Add support for Authen::Simple (all Authen::Simple modules can be used directly as Drivers) - Made the login page much more customizable: - change any of the text - customize the colours - provide one base colour and lighter and darker shades are automatically generated (requires Color::Calc) - offer to remember the users username in a cookie for the next time they login - add option for a 'forgotten password' URL - add option for a 'register new account' URL - add option to supress the stylesheet so you can provide your own Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC2: CGI::Application::Plugin::RateLimit
On 5/3/06, Sam Tregar [EMAIL PROTECTED] wrote:
# keep people from calling 'send' more often than 5 times in 10
# minutes and 'list' more often than once every 5 seconds.
$rate_limit-protected_modes(send = {timeframe = '10m',
max_hits = 5
},
list = {timeframe = '5s',
max_hits = 1
});
Nothing that is needed for a first version, but as an alternative to
'protected_modes' it might be nice to also allow that info to be
provided in an attribute. It keeps the information close to where it
is actually applied:
sub send :RateLimit(max_hits=5, timeframe=10s) {
my $self = shift;
...
}
We've been talking on IRC about providing better support for
attributes in CGI::Application, which can be tricky to get right when
lots of plugins are providing attributes.
Other than that suggestion, this plugin looks well thought out and useful.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] OT: apache logout and a javascript question
On 5/2/06, Michael Lackhoff [EMAIL PROTECTED] wrote: I followed the advice from this list and wrote mod_perl authentification- and authorization handlers to move this task from my application to apache. But now I have the problem that for this kind of authentification there is no 'logout' functionallity. How do others handle this problem? The best I could come up with was a tweak to the authentification handler that gives back an 401 error to everyone for the location /myapp/logout and then write my own error document for this location saying Logout successful or something like that. But still the user gets the pop up box from the browser to reauthentificate. Any better ideas? The only way to get the browser to popup another authentication box is to send a different realm with the authentication request. But there is no way to tell the browser to 'forget' the username and password that the user typed in. This is one of the main reasons why so many people use cookie or URL based authentication schemes, since basic authentication is so limited. Check out Apache::AuthCookie for an apache module that uses cookie based authentication. Cheers, Cees My second question is really off topic but perhaps someone can give me a short hint. I need a pair of multiple select boxes where one can move entries from one box to the other by clicking on an arrow button. There are some scripts out there that do what I want but I would prefer not to include many little script files to my application but rather do such stuff with the help of the big libraries like prototype and scriptaculous that I need anyway and that are well maintained. Does anyone know a solution based on one of these (or similar) libraries? Thanks, Michael - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Upload meter plugin/tutorial?
On 5/2/06, Barry Hoggard [EMAIL PROTECTED] wrote: I'm getting ready to add an upload meter to some CGI::Application- based applications, running under mod_perl (1.x). Is there a plugin I've missed, or a tutorial somewhere I could use? Otherwise I'll just adapt something from one of the CPAN modules. For mod_perl 1 there is the old Apache::UploadMeter, but that is pretty limited and not very flexible. For mod_perl 2, I just released Apache2::UploadProgress (along with Christian Hansen). It is extremely flexible and you can get it to work without needing to make any changes to your code. You just need to add an onsubmit call to your upload form and the rest is handled for you behind the scenes. See the following URL for a demo: http://cees.crtconsulting.ca/perl/examples/uploadprogress/embedded.cgi http://cees.crtconsulting.ca/perl/examples/uploadprogress/popup.cgi But since you mention mod_perl 1, I guess you will have to do a lot of the work yourself. You should at least be able to get some ideas on the clients side stuff from Apache2::UploadProgress (like the JavaScript). Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Upload meter plugin/tutorial?
On 5/2/06, Ron Savage [EMAIL PROTECTED] wrote: On Tue, 2 May 2006 14:10:46 -0400, Cees Hek wrote: Hi Cees But since you mention mod_perl 1, I guess you will have to do a lot Does it work for Registry scripts? Does what work for Registry scripts? If you are talking Apache2::UploadMeter, then it will work with anything at all, as long as you are running Apache2 and mod_perl2. It will work with static pages, CGI scripts, mod_perl2 handlers, PHP scripts. Anything you want. If you are using mod_perl 1, then you can use Apache::UploadMeter, which will work with registry scripts (but you can only configure one uploadmeter for the server). if you do it manually, then you can do it in a CGI script or a registry script, but you need to do all the work yourself (using the UPLOAD_HOOK in mod_perl or CGI.pm). Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Upload meter plugin/tutorial?
On 5/2/06, Ron Savage [EMAIL PROTECTED] wrote: Does what work for Registry scripts? If you are talking Sorry, should have spelled it out. Apache2::UploadMeter? Ahh, I see on CPAN: Apache2::UploadProgress. I meant: Did Apache2::UploadProgress work when called from code which is not a mod_perl handler? The answer is Yes! In case anyone is interested in seeing how easy it is to setup, here is all you need to add an uploadmeter to your form using Apache2::UploadProgress: Add these two lines to your apache2 config file and restart: PerlLoadModule Apache2::UploadProgress PerlPostReadRequestHandler Apache2::UploadProgress Load the following script and css file in your HTML document (they magically exist on your apache server if you load the Apache2::UploadProgress module, no need to copy the files anywhere): script src=/UploadProgress/progress.js/script link type=text/css href=/UploadProgress/progress.css/ And then in your HTML form tag add this onsubmit call: onsubmit=return startPopupProgressBar(this) Or if you want to embed the uploadmeter in the page, use this onsubmit call and add an extra div to the page: onsubmit=return startEmbeddedProgressBar(this) div id=progress/div That is all that is needed. The script that processes the form does not need to be changed at all, in fact, it doesn't even know that an uploadmeter is being used, and it shouldn't care about it. Apache and mod_perl handle everything behind the scenes. Here is a full example: script src=/UploadProgress/progress.js/script link type=text/css href=/UploadProgress/progress.css/ form action=/cgi-bin/script.cgi method=post enctype=multipart/form-data onsubmit=return startEmbeddedProgressBar(this) input type=file name=file/ input type=submit name=.submit/ /form div id=progress/div Paste that into an HTML page and give it a whirl! Or try the demos: http://cees.crtconsulting.ca/perl/examples/uploadprogress/embedded.cgi http://cees.crtconsulting.ca/perl/examples/uploadprogress/popup.cgi Cheers, Cees ps If anyone is interested in helping out with this module, please speak up. There is a TODO file with stuff that is in the works. I'd also love to see more CSS stylesheets for different types of progress bars. Or, if you are just trying it out, let me know what you think... - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] More base class questions
On 4/29/06, Ed Pigg [EMAIL PROTECTED] wrote:
I've split my application run modes into several modules and a base
class.
myapp.pm
somestuff.pm
someotherstuff.pm
I want to put the common code in the base class. Session management -
CGI::Application::Plugin::Session, Authentication -
CGI::Application::Plugin::Authentication, etc..
I'm having a problem getting the derived modules to call base class
methods. Do I need to export the methods?
package myapp::Base;
use strict;
use warnings;
use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Authentication;
use base 'CGI::Application';
sub common_function {
}
package myapp::somestuff;
use strict;
use warnings;
use base 'myapp::Base';
my somestuff_function {
my $self = shift;
my $value = $self-common_function();- error
common_function not found
}
Shouldn't all of the base class functions be inherited?
Yes. What you have there should work. Make sure you are not making
some simple spelling mistakes somewhere.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Long running modes - how to display please wait?
On 4/27/06, B Wooster [EMAIL PROTECTED] wrote: On 4/27/06, Michael Peters [EMAIL PROTECTED] wrote: Well, it's kind of hard to give you more ideas unless we know why you don't like those other 2 and exactly why they won't give you what you're after. Having said that... Oh, I'm fine with headers-none, but not sure if there was any better or prefered way. That's all Currently with CGI::Application there is no better way of doing this. I have talked before about wanting CGI::Application to be able to accept a coderef as a return value from a runmode (instead of just a string of HTML). That would allow CGI::App to still send out all the headers, and then when it needs to send the results to the browser, it can just call the coderef and send its return value (or it can call the coderef repeatedly until it receives no more output - I haven't thought about it in too much detail). It would be pretty simple to add this to CGI::App, but I have never bothered to code it up and submit a working patch. This would potentially end up simplifying the CAP::Stream plugin as well... Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application::Plugin::Session - Changing the cookie name
On 4/27/06, Ed Pigg [EMAIL PROTECTED] wrote:
The doc's for CGI::Application::Plugin::Session state
NOTE: If you change the name of the cookie by passing a -name
parameter, remember to notify CGI::Session of the change by calling
CGI::Session-name('new_cookie_name').
At what point is this call made? In the Session options? Before the
session_config or after?
In my Base package I have the following init.
sub cgiapp_init {
my $self = shift;
$self-session_config(
CGI_SESSION_OPTIONS = [ driver:mysql, $self-query, {
DataSource
= $ENV{DB_DSN},
User= $ENV{DB_USER},
Password= $ENV{DB_PWD}
} ],
COOKIE_PARAMS = {-name = 'MYCOOKIENAME',
-expires = +1y,
-path = '/', },
SEND_COOKIE = 1,
);
}
I think those docs may be a little out of date. The send_cookie
mechanism in CAP::Session checks with CGI::Session to find out what
the cookie name is, and uses that. So you do not need to use
COOKIE_PARAMS = { -name = 'MYCOOKIENAME' }.
All you really need to do is call:
CGI::Session-name('MYCOOKIENAME')
And you can just put that in the global scope of your program (right
after you load CAP::Session if you like)
Just remember that if you are using mod_perl or another persistent
environment that this will change the cookie name for all applications
that run under the perl interpreter (CGI::Session keeps the name as a
global variable).
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Long running modes - how to display please wait?
On 4/27/06, B Wooster [EMAIL PROTECTED] wrote:
Found one more reason why I thought header_type('none') usage may run
into conflict - the doc has this paragraph - but how can I not use
print to display new lines (done step1, done step2, etc) to the web
page?
From docs:
IMPORTANT NOTE ABOUT RUN MODE METHODS
Your application should *NEVER* print() to STDOUT. Using print() to
send output to STDOUT (including HTTP headers) is exclusively the
domain of the inherited run() method. Breaking this rule is a common
source of errors. If your program is erroneously sending content
before your HTTP header, you are probably breaking this rule.
That is why the header_type('none') is a bit of a hack. You have to
handle stuff that CGI::App is suposed to handle for you. When you set
header_type('none'), you have to send out the headers yourself, and
then you can call 'print' in your runmode to your hearts content, and
at the end you can just return ''.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Checking expired session in cgiapp_prerun stage
On 4/26/06, Anthony Chee [EMAIL PROTECTED] wrote: I would like to check whether the session expired in cgiapp_prerun stage, but got some problem The condition is that the application will not go to mode page6 (showSessionExpire) after I logged in the system and idle for more than 1 min, it just run into page1, ie, conition $self-session-is_new() met, and new session is generated. I checked that CGI-Application-Plugin-Session manual page and found This effectively creates a singleton session object for the duration of the request. CGI::Session will look for a cookie or param containing the session ID, and create a new session if none is found.. Does it mean that expired session will not be loaded, and create a new session instead? Most likely, the cookie is being expired on the client, and is not being sent to the server. Which means CGI::Session can not know that a session was expired, because it is not given a session ID. You should try and set the cookie expiry time to be later than the session expiry time. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Checking expired session in cgiapp_prerun stage
On 4/26/06, Anthony Chee [EMAIL PROTECTED] wrote:
I did not use cookie in my application
CGI::Application::Plugin::Session uses cookies by default, and does so
automatically, so since you don't shw any configuration that turned
off the cookie support, I assumed you must be using cookies.
I know that there are new() and load() method in CGI::Session. To check
whether the session is expired, first use load() to load the existing
session and use is_expired() to check whether the session is expired. It
seems that CGI::Application::Plugin::Session only use new(), a new session
will be created automatically when there is no session before or the session
is expired.
a call to $self-session has to return a valid usable session. If it
didn't, then you would have to put code like this throughout your
CGI::Application code:
my $session = $self-session;
if ($session-is_empty) {
# handle empty session
} else {
# use the session
}
So using 'load' is not an option. The only useful scenario I see for
using 'load' is when you want to check to see if a session is there
without actually creating a session. To use it to check to see if a
session is expired seems akward and annoying (that is not blaming your
use, but blaming CGI::Session for an annoying interface).
However, I ran some tests, and it looks like 'load' is not needed to
detect expired sessions. Since 'new' actually calls 'load'
internally, the 'is_expired' flag will be set even when calling 'new'.
So really the CGI::Session docs should be clarified with the example
it gives for detecting expired sessions.
I have attached a program that tests the different scenarios, and here
is the output:
No Session ID passed in:
7b4692ecd080a72c70f8b347eedb8718 new Yes
7b4692ecd080a72c70f8b347eedb8718 expired No
Valid Session ID passed in and session is in the store:
7b4692ecd080a72c70f8b347eedb8718 new No
7b4692ecd080a72c70f8b347eedb8718 expired No
Valid Session ID passed in and session is in the store, but session has expired:
5cbab661beddf73521712eae16dd7e6e new Yes
5cbab661beddf73521712eae16dd7e6e expired Yes
Valid Session ID passed but session not in the store:
7392ed0df216591b35e35183ed33dc23 new Yes
7392ed0df216591b35e35183ed33dc23 expired No
To me that should be enough information to display a 'Your session has
been expired' message.
Cheers,
Cees
session.pl
Description: Perl program
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Creating SuperClass for my application
On 4/24/06, Ed Pigg [EMAIL PROTECTED] wrote:
Hi list,
I'm trying to get the concept of creating a super class for my
application and understand what elements need to be included in the
base application module.
Let's say I want to create a web app called MyApp. My Directory
structure looks like this ...
/MyApp
Base.pm
User.pm
Inventory.pm
Other.pm
My Base class would be
package MyApp::Base.pm
use base 'CGI::Application';
sub cgiapp_init {...};
sub cgiapp_prerun {...};
sub _some_common_code {...};
1;
Then all of my other packages will contain the run modes for that
module and can call methods from the base class as long as they are
setup as follows
package MyApp::User.pm;
use base 'MyApp::Base';
sub cgiapp_init {
my $self = shift;
$self-start_mode( 'display_users' );
$self-tmpl_path( set_template_path_here );
$self-run_modes( qw/ display_users display_user_form edit_user /);
... module specific init items here
}
sub display_users {...}
sub display_user_form {...}
sub edit_user {...}
1;
Am I understanding the layout correctly?
Yes, except that in your subclass example, the fact that you create a
new 'cgiapp_init' method will override the 'cgiapp_init' method in
your base class. That means the 'cgiapp_init' method in your base
class will not get executed. That may be desired, but if it is not,
then you can call the 'cgiapp_init' method in the base class directly
by adding the following line to your 'cgiapp_init' method in your
subclass:
$self-SUPER::cgiapp_init(@_);
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Creating SuperClass for my application
On 4/24/06, Ed Pigg [EMAIL PROTECTED] wrote:
So how I put things like session initialization, database connection,
etc.. in the SUPER::cgiapp_init sub. So my SUB CLASS would be
something like
sub cgiapp_init {
my $self = shift;
$self-SUPER::cgiapp_init(@_);
$self-start_mode();
$self-run_modes( ... );
}
Yes, that would work. But if you are doing stuff like session init
and database connections, and you are sure you want to do this on all
requests, for every runmode, then I would suggest using Michael's
suggestion and set up a callback (which will always run regardless of
what you do in the subclass). That is safer, since you don't have to
remember to add that SUPER call in the subclass everytime.
__PACKAGE__-add_callback(init = \_my_init);
Just put that at the top of your base class somewhere (not inside a
subroutine), and make sure you are using at least CGI::Application
4.0, which is when the callback code was added. That will execute the
_my_init method for every runmode request during the 'init' stage.
The only problem you may run into, is that the init callbacks are
called immediately after the cgiapp_init method is called. So your
subclass can not do anything in cgiapp_init that depends on something
that happens in your init callback, since it will not have been
executed yet.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] session no default expiration = no deletion ?
On 4/13/06, Giannis Economou [EMAIL PROTECTED] wrote: Suppose someone uses CAP::Session without expiration time (DEFAULT_EXPIRY parameter not set) and suppose sessions are written to files on disk. When will these sessions be removed from the disk? Never ( = until someone cleans the storage)? If so, isn't it better to keep a long expiry time in order to be auto-removed by CGI::Session? As far as I know CGI::Session only ever deletes a session if you ask for it, and it has expired. So even if you put a long expiry on the session, CGI::Session will not delete it for you unless a request comes in for that particular session. You need to manually run a purge to delete expired sessions. I manage expiring session in one of two ways: 1. Use the File based sessions, and use a find command to find old sessions and delete them. 2. Use the postgres driver, and add an extra timestamp column to the table that automatically updates on updates to the table: CREATE TABLE sessions ( id varchar(32) NOT NULL PRIMARY KEY, a_session text NOT NULL, lm timestamp with time zone DEFAULT now() ); CREATE FUNCTION update_session_lm() RETURNS trigger AS ' BEGIN NEW.lm := ''now''; RETURN NEW; END; ' LANGUAGE plpgsql; CREATE TRIGGER update_session_lm_trig BEFORE UPDATE ON sessions FOR EACH ROW EXECUTE PROCEDURE update_session_lm(); That way you can easily run a query that deletes all the old sessions. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] session no default expiration = no deletion ?
On 4/13/06, Giannis Economou [EMAIL PROTECTED] wrote:
Thank you Cees.
I see I would expect this to be handled by CGI::Session though.
The reason this isn't handled by CGI::Session is for performance
reasons. Say you have 10,000 active session on disk, and you load up
a new session -- should CGI::Session parse through each of those
10,000 files to expiry the old ones before loading up the session you
just asked for? That would be crazy. It would do it every time you
loaded a session. Even if you were able to store some info somewhere
and only purge once and hour, if you happen to be the unlucky user
that hits the process that does the purge, you may be waiting for your
page to load for several minutes.
It just isn't practical to do it in real time, so it has to be done
behind the scenes.
And after reading your message (next time do it before even posting,
Giannis!) I've looked again the perldoc of CGI::Session. There is a
method (marked as 'experimental feature') called find(\code).
Ok, next one is from the perldoc:
Following line, for instance, will remove sessions already expired, but
are still in disk:
CGI::Session-find( sub {} );
I believe that function will load up and decode every session in the
store to check it's expiry time. It is really inefficient for large
numbers of sessions. That is why the 'find' command is much better
for files, and that is why I use the extra timestamp column for the
database sessions.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] error in CAP::Redirect?
On 4/12/06, Giannis Economou [EMAIL PROTECTED] wrote:
I guess this one goes to the Maintainer of CAP::Redirect, but maybe
someone has experienced that too and might tell an opinion.
In the log file of my C::A (don't bother with the custom format), I get
the following error:
Antithesis::WebApp::BaseApp::__ANON__ == prerun_mode() can only be
called within cgiapp_prerun()! Error at
/home/virtual/site192/fst/home/foo/bar/lib/perl5/site_perl/5.8.0/CGI/Application/Plugin/Redirect.pm
line 23
Do you have a $SIG{__DIE__} handler in your code somewhere or are you
overriding CORE::die (maybe through the use of a logging module? That
is the only way I can explain why you would see that error message.
If you look in the code for CAP::Redirect, you will see that it is
very simple. Here is the code in question:
# The eval may fail, but we don't care
eval {
$self-run_modes( dummy_redirect = sub { } );
$self-prerun_mode('dummy_redirect');# === line 23
};
So you see that it does call prerun_mode, but it calls it inside an
eval block which means the error is captured (and promptly ignored).
The application seems to work right, through the browser doing the
redirect. It is on Enterprise Redhat linux, on apache 2.x with perl
5.8.0 (as seen in the error), as plain cgi. I don't know it might be a
bug (if so I can report it more officially), but seems to work so far.
The app works correctly, since the eval captured the error and ignored it.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] YAPC CGI::App talks revisited
Hi Michael, I have submitted a talk on AJAX for perl programmers for the upcoming YAPC conference. I will probably be using some simple CGI::App examples during that talk (if it gets accepted), but it will not focus on CGI::App directly. Maybe someone else out there wants to give a shot at a CGI::App talk? Cheers, Cees On 4/7/06, Michael Graham [EMAIL PROTECTED] wrote: It was great to see all the cgiapp people at YAPC in Toronto last year (despite the fact that I was crazy sleep deprived the whole time). I hope I'll be seeing you all again at this year's YAPC in Chicago! I'm not sure if I'm going to submit a talk yet, but like most people here, I think *somebody* should be speaking about CGI::Application. It would be good for promotion and to show that whole world hasn't gone completely Catalyst. Some potential talk topics have been brought up on IRC and on the list. Note that I'm not trying to volunteer anybody for anything! Just throwing out some ideas: - CGI::Application::Dispatch (v2) (Maybe Michael Peters would like to speak on the new version? :) - The Authen and Authz plugins (Maybe Cees could talk about these? :) - AJAX and CGI::Application (Maybe Cees could do this one too? :) :) - CGI::Application - the flexible web development platform - one of the unique features of C::A is flexibility - it can be as lightweight or heavyweight as you want. - You can start simple with a couple of templates and an instance script and as you grow, you add plugins that suit your development style. - Seven essential CGI::Application plugins - Seven people could each speak for 5 minutes on their favourite plugin. A great way to showcase all the things that C::A can do. Any others? As I say, I'm not sure if I'm going to submit a talk myself, but I probably will if noone else is going to. So it would be great to get some feedback before Monday to see what people are planning (if anything). And if anybody wants to participate in the seven plugins talk, let me know! Michae --- Michael Graham [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
