Re: [cgiapp] draft version of PSGI::Application and load_tmpl replacement
On 6/11/2012 8:36 μμ, Mark Stosberg wrote: On 11/06/2012 12:27 PM, Kurt Lidl wrote: On 11/6/2012 12:24 PM, Mark Stosberg wrote: * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. I'd vote for lower-casing them, if you're looking for feedback. I am looking for feedback. Thanks for the opinion. Mark Hello... IMHO, there should be no enforcement. If that was a convention I suggest to keep it like this. Conventions play well with TIMTOWTDI, too... A discussion on the convention would be ok, but I believe that such enforcements are not really necessary. Documentation can suggest the convention. This is my opinion, if I'm not missing something... +1 for the rest of the API changes. Giannis # 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 to use C::A::Dispatch with FastCGI ?
Mark Fuller wrote: On Sun, Feb 24, 2008 at 3:34 AM, Giannis Economou [EMAIL PROTECTED] wrote: Actually, the best thing for me was to use the mod_fcgid module (http://fastcgi.coremail.cn/) instead of the old fastcgi (www.fastcgi.com). mod_fcgid is binary compatibility to mod_fastcgi, but I like it much more. Thanks. I wasn't aware there was a fastcgi and fastcgid. It sounds like this is just a change at the Apache server, not the instance script? You continue to use FCGI.pl? (There's not an FCGId.pl?). Yes, you continue using FCGI (no FCGId). I googled and found a couple of people saying the d handler is unstable (one said it's more unstable than a monkey on crack). That was posted in the past 60 days. Have you had any problems? None! No problems. Running non-stop for many months without any problem at all. Give it a try. Giannis # 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 to use C::A::Dispatch with FastCGI ?
Hello...
I'm using fastcgi for C::A for a long time in production installations,
with success (with C::A::Dispatch).
Actually, the best thing for me was to use the mod_fcgid module
(http://fastcgi.coremail.cn/) instead of the old fastcgi (www.fastcgi.com).
mod_fcgid is binary compatibility to mod_fastcgi, but I like it much more.
mod_fcgid become more popular after RoR success - it seems it become
quite common accelerator for ruby environments nowadays.
Installation is pretty easy. And it's working reliable for accelarating
my C::A non-stop in production environments.
In the past (before mod_fcgid) I had several experiences with speedycgi
(aka perperl) and C::A (with Dispatch). But I abandon this, because
there were problems. It was 2006 and I don't remember exactly the
problems I had. I remember that I've managed to have speedycgi running
and it seemed ok.
But the processes of speedycgi was becoming problematic after some
days/weeks of execution. Maybe it had to do with database persistency, I
really do not remember now. I remember also that I was very pleased to
abandon speedy and to go to mod_fcgid.
BTW, if you are interested we offer shared hosting that is ready for
C::A (wth mod_fcgi), in case you are interested. Our systems run CentOS
4, 5 (and Debian, but our Debian servers are not available for shared
hosting now).
To make a plain CGI C::A to go on Fast CGI (mod_fcgi), usually I just
have to:
use CGI::Fast qw(:standard);
and then implement the main loop, as:
while ( my $q = new CGI::Fast ) {
...
}
I also use in the dispatch() options:
args_to_new = {
QUERY = $q,
PARAMS = {
'::Plugin::DBH::dbh_config' = [ sub
{DBI-connect_cached(
MyWebApp::Util::Config-instance-GetDbConnectionParams() );} ],
},
(Util::Config-GetDbConnectionParams() just returns the connection string)
I also take care to not relyi on any relative paths in my C::A.
Best regards,
Giannis Economou
Ron Savage wrote:
On Thu, 2008-02-21 at 09:59 +0800, Silent wrote:
Hi Slient
has anyone use C-A-Dispatch with FastCGI ?
I had no trouble using it. I can send my code it that helps.
# 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] Bug-Problem with CGI.pm, fcgid, CGI::Application and utf-8?
Hello,
I'm writing to report a nasty situation/bug I'm facing. It is quite
strange to me, I can not find out which component might be fully
responsible (maybe just CGI.pm or the combination of C::A and CGI.pm)
and I gave some hours to isolate the situation as much as possible and
reproduce it. Maybe someone is also interest or can help.
I explain and afterwards I send you some sample code you can try.
I have some applications written, now in production installation, using
C::A. They are different apps, using many CGI::App modules and C::A
Plugins and they show output (html) in utf-8. Among other they also use
TT2, but this is also irrelevant to the problem.
All started when I accidentally found out that when cookies are disabled
(in firefox or ie) then web pages do not display the utf-8 correctly,
but when cookies are enabled, everything is displayed correctly!
I've managed to isolate the problem (as you can guess I started being
suspicious with many modules in the way before stripping everything in a
new test case).
It happens only with:
- C::A applications (simple cgi script are not having the problem)
- running on my server (Linux, Apache/2.0.52, Perl v5.8.5), I haven't
tried other servers, but I guess it will be also have the problem
- only when run under fcgid acceleration (plain cgi execution has
consistent behavior), I also tried the latest fcgid module on my Apache
no luck
- only when using CGI.pm (with CGI::Simple this problem is not
happening, utf-8 is always displayed right) - my CGI.pm is version 3.31.
It is frustrating, mostly because I was really happy with fcgid as
acceleration of my apps until today. Now I had to switch to plain cgi again.
Here is a sample source that demonstrates and reproduce the problem,
using the bare/minimal modules to reproduce it:
### (instance.fcgi) ###
#!/usr/bin/perl
use CGI::Fast;
use WebApp;
while (new CGI::Fast) {
my $self = WebApp-new();
$self-run();
}
### (WebApp.pm) ###
package WebApp;
use base 'CGI::Application';
sub setup {
my $self = shift;
$self-start_mode('test');
$self-mode_param('rm');
$self-run_modes(
'test' = 'show_test',
);
$self-header_add( -charset = 'utf-8' );
}
sub show_test {
my $self = shift;
my $cookie = $self-query-cookie(-name='test', -value='foo');
$self-header_add(-cookie=$cookie); #set the cookie
return Hello ... Καλημέρα!; #this is 'Good morning' in Greek, file is
saved as utf-8
}
1;
Now:
- when you run the instance.fcgi as fcgid script, cookie is set and in
browser you get garbage in the Greek text (encoding is correctly set in
browser).
- when you run the instance.fcgi as plain cgi script, everything is fine
- when you comment the cookie setting line in WebApp.pm, everything is
working fine, regardless of fcgid or plain cgi.
- when you use CGI::Simple instead of CGI.pm (for example use a
CGI::Simple object instead of $self-query which is a CGI.pm in the
example above to create the cookie), everything is working fine (fcgi /
plain cgi, set cookie / do not set cookie, everything is fine).
Here is the output of CGI::Application, as sent in browser, but as
unicode codes:
Correct:
Hello ... \xce\x9a\xce\xb1\xce\xbb\xce\xb7\xce\xbc\xce\xad\xcf\x81\xce\xb1!
Erroneous:
Hello ...
\xc3\x8e\xc2\x9a\xc3\x8e\xc2\xb1\xc3\x8e\xc2\xbb\xc3\x8e\xc2\xb7\xc3\x8e\xc2\xbc\xc3\x8e\xc2\xad\xc3\x8f\xc2\x81\xc3\x8e\xc2\xb1!
Best regards,
Giannis Economou
# 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] Bug-Problem with CGI.pm, fcgid, CGI::Application and utf-8?
Hello,
I'm writing to report a nasty situation/bug I'm facing. It is quite
strange to me, I can not find out which component might be fully
responsible (maybe just CGI.pm or the combination of C::A and CGI.pm)
and I gave some hours to isolate the situation as much as possible and
reproduce it. Maybe someone is also interest or can help.
I explain and afterwards I send you some sample code you can try.
I have some applications written, now in production installation, using
C::A. They are different apps, using many CGI::App modules and C::A
Plugins and they show output (html) in utf-8. Among other they also use
TT2, but this is also irrelevant to the problem.
All started when I accidentally found out that when cookies are disabled
(in firefox or ie) then web pages do not display the utf-8 correctly,
but when cookies are enabled, everything is displayed correctly!
I've managed to isolate the problem (as you can guess I started being
suspicious with many modules in the way before stripping everything in a
new test case).
It happens only with:
- C::A applications (simple cgi script are not having the problem)
- running on my server (Linux, Apache/2.0.52, Perl v5.8.5), I haven't
tried other servers, but I guess it will be also have the problem
- only when run under fcgid acceleration (plain cgi execution has
consistent behavior), I also tried the latest fcgid module on my Apache
no luck
- only when using CGI.pm (with CGI::Simple this problem is not
happening, utf-8 is always displayed right) - my CGI.pm is version 3.31.
It is frustrating, mostly because I was really happy with fcgid as
acceleration of my apps until today. Now I had to switch to plain cgi again.
Here is a sample source that demonstrates and reproduce the problem,
using the bare/minimal modules to reproduce it:
### (instance.fcgi) ###
#!/usr/bin/perl
use CGI::Fast;
use WebApp;
while (new CGI::Fast) {
my $self = WebApp-new();
$self-run();
}
### (WebApp.pm) ###
package WebApp;
use base 'CGI::Application';
sub setup {
my $self = shift;
$self-start_mode('test');
$self-mode_param('rm');
$self-run_modes(
'test' = 'show_test',
);
$self-header_add( -charset = 'utf-8' );
}
sub show_test {
my $self = shift;
my $cookie = $self-query-cookie(-name='test', -value='foo');
$self-header_add(-cookie=$cookie); #set the cookie
return Hello ... Καλημέρα!; #this is 'Good morning' in Greek, file is
saved as utf-8
}
1;
Now:
- when you run the instance.fcgi as fcgid script, cookie is set and in
browser you get garbage in the Greek text (encoding is correctly set in
browser).
- when you run the instance.fcgi as plain cgi script, everything is fine
- when you comment the cookie setting line in WebApp.pm, everything is
working fine, regardless of fcgid or plain cgi.
- when you use CGI::Simple instead of CGI.pm (for example use a
CGI::Simple object instead of $self-query which is a CGI.pm in the
example above to create the cookie), everything is working fine (fcgi /
plain cgi, set cookie / do not set cookie, everything is fine).
Here is the output of CGI::Application, as sent in browser, but as
unicode codes:
Correct:
Hello ... \xce\x9a\xce\xb1\xce\xbb\xce\xb7\xce\xbc\xce\xad\xcf\x81\xce\xb1!
Erroneous:
Hello ...
\xc3\x8e\xc2\x9a\xc3\x8e\xc2\xb1\xc3\x8e\xc2\xbb\xc3\x8e\xc2\xb7\xc3\x8e\xc2\xbc\xc3\x8e\xc2\xad\xc3\x8f\xc2\x81\xc3\x8e\xc2\xb1!
Best regards,
Giannis Economou
# 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] Bug-Problem with CGI.pm, fcgid, CGI::Application and utf-8?
Hello,
I'm writing to report a nasty situation/bug I'm facing. It is quite
strange to me, I can not find out which component might be fully
responsible (maybe just CGI.pm or the combination of C::A and CGI.pm)
and I gave some hours to isolate the situation as much as possible and
reproduce it. Maybe someone is also interest or can help.
I explain and afterwards I send you some sample code you can try.
I have some applications written, now in production installation, using
C::A. They are different apps, using many CGI::App modules and C::A
Plugins and they show output (html) in utf-8. Among other they also use
TT2, but this is also irrelevant to the problem.
All started when I accidentally found out that when cookies are disabled
(in firefox or ie) then web pages do not display the utf-8 correctly,
but when cookies are enabled, everything is displayed correctly!
I've managed to isolate the problem (as you can guess I started being
suspicious with many modules in the way before stripping everything in a
new test case).
It happens only with:
- C::A applications (simple cgi script are not having the problem)
- running on my server (Linux, Apache/2.0.52, Perl v5.8.5), I haven't
tried other servers, but I guess it will be also have the problem
- only when run under fcgid acceleration (plain cgi execution has
consistent behavior), I also tried the latest fcgid module on my Apache
no luck
- only when using CGI.pm (with CGI::Simple this problem is not
happening, utf-8 is always displayed right) - my CGI.pm is version 3.31.
It is frustrating, mostly because I was really happy with fcgid as
acceleration of my apps until today. Now I had to switch to plain cgi again.
Here is a sample source that demonstrates and reproduce the problem,
using the bare/minimal modules to reproduce it:
### (instance.fcgi) ###
#!/usr/bin/perl
use CGI::Fast;
use WebApp;
while (new CGI::Fast) {
my $self = WebApp-new();
$self-run();
}
### (WebApp.pm) ###
package WebApp;
use base 'CGI::Application';
sub setup {
my $self = shift;
$self-start_mode('test');
$self-mode_param('rm');
$self-run_modes(
'test' = 'show_test',
);
$self-header_add( -charset = 'utf-8' );
}
sub show_test {
my $self = shift;
my $cookie = $self-query-cookie(-name='test', -value='foo');
$self-header_add(-cookie=$cookie); #set the cookie
return Hello ... Καλημέρα!; #this is 'Good morning' in Greek, file is
saved as utf-8
}
1;
Now:
- when you run the instance.fcgi as fcgid script, cookie is set and in
browser you get garbage in the Greek text (encoding is correctly set in
browser).
- when you run the instance.fcgi as plain cgi script, everything is fine
- when you comment the cookie setting line in WebApp.pm, everything is
working fine, regardless of fcgid or plain cgi.
- when you use CGI::Simple instead of CGI.pm (for example use a
CGI::Simple object instead of $self-query which is a CGI.pm in the
example above to create the cookie), everything is working fine (fcgi /
plain cgi, set cookie / do not set cookie, everything is fine).
Here is the output of CGI::Application, as sent in browser, but as
unicode codes:
Correct:
Hello ... \xce\x9a\xce\xb1\xce\xbb\xce\xb7\xce\xbc\xce\xad\xcf\x81\xce\xb1!
Erroneous:
Hello ...
\xc3\x8e\xc2\x9a\xc3\x8e\xc2\xb1\xc3\x8e\xc2\xbb\xc3\x8e\xc2\xb7\xc3\x8e\xc2\xbc\xc3\x8e\xc2\xad\xc3\x8f\xc2\x81\xc3\x8e\xc2\xb1!
Best regards,
Giannis Economou
# 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] Bug-Problem with CGI.pm, fcgid, CGI::Application and utf-8?
Hello,
I'm writing to report a nasty situation/bug I'm facing. It is quite
strange to me, I can not find out which component might be fully
responsible (maybe just CGI.pm or the combination of C::A and CGI.pm)
and I gave some hours to isolate the situation as much as possible and
reproduce it. Maybe someone is also interest or can help.
I explain and afterwards I send you some sample code you can try.
I have some applications written, now in production installation, using
C::A. They are different apps, using many CGI::App modules and C::A
Plugins and they show output (html) in utf-8. Among other they also use
TT2, but this is also irrelevant to the problem.
All started when I accidentally found out that when cookies are disabled
(in firefox or ie) then web pages do not display the utf-8 correctly,
but when cookies are enabled, everything is displayed correctly!
I've managed to isolate the problem (as you can guess I started being
suspicious with many modules in the way before stripping everything in a
new test case).
It happens only with:
- C::A applications (simple cgi script are not having the problem)
- running on my server (Linux, Apache/2.0.52, Perl v5.8.5), I haven't
tried other servers, but I guess it will be also have the problem
- only when run under fcgid acceleration (plain cgi execution has
consistent behavior), I also tried the latest fcgid module on my Apache
no luck
- only when using CGI.pm (with CGI::Simple this problem is not
happening, utf-8 is always displayed right) - my CGI.pm is version 3.31.
It is frustrating, mostly because I was really happy with fcgid as
acceleration of my apps until today. Now I had to switch to plain cgi again.
Here is a sample source that demonstrates and reproduce the problem,
using the bare/minimal modules to reproduce it:
### (instance.fcgi) ###
#!/usr/bin/perl
use CGI::Fast;
use WebApp;
while (new CGI::Fast) {
my $self = WebApp-new();
$self-run();
}
### (WebApp.pm) ###
package WebApp;
use base 'CGI::Application';
sub setup {
my $self = shift;
$self-start_mode('test');
$self-mode_param('rm');
$self-run_modes(
'test' = 'show_test',
);
$self-header_add( -charset = 'utf-8' );
}
sub show_test {
my $self = shift;
my $cookie = $self-query-cookie(-name='test', -value='foo');
$self-header_add(-cookie=$cookie); #set the cookie
return Hello ... Καλημέρα!; #this is 'Good morning' in Greek, file is
saved as utf-8
}
1;
Now:
- when you run the instance.fcgi as fcgid script, cookie is set and in
browser you get garbage in the Greek text (encoding is correctly set in
browser).
- when you run the instance.fcgi as plain cgi script, everything is fine
- when you comment the cookie setting line in WebApp.pm, everything is
working fine, regardless of fcgid or plain cgi.
- when you use CGI::Simple instead of CGI.pm (for example use a
CGI::Simple object instead of $self-query which is a CGI.pm in the
example above to create the cookie), everything is working fine (fcgi /
plain cgi, set cookie / do not set cookie, everything is fine).
Here is the output of CGI::Application, as sent in browser, but as
unicode codes:
Correct:
Hello ... \xce\x9a\xce\xb1\xce\xbb\xce\xb7\xce\xbc\xce\xad\xcf\x81\xce\xb1!
Erroneous:
Hello ...
\xc3\x8e\xc2\x9a\xc3\x8e\xc2\xb1\xc3\x8e\xc2\xbb\xc3\x8e\xc2\xb7\xc3\x8e\xc2\xbc\xc3\x8e\xc2\xad\xc3\x8f\xc2\x81\xc3\x8e\xc2\xb1!
Best regards,
Giannis Economou
# 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] CGI to FastCGI (mod_fcgid) (using CA::Dispatch)
Hello, I have an application running as plain CGI which is using CA::Dispatch. I want to use FastCGI (especially mod_fcgid) from now on. Do you have any considerations or suggestions in mind that someone should pay attention to when doing the switching? Should I do something special or changing the apache handler should be enough without any changes to the source code? Thank you, Giannis - 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] CAP packaging and deployment
Hi... I'm writing as to share our experiences and ideas on the packaging and the deployment of CAP on servers. I'm using CAP for a long time now and for me is by far the best way to develop web applications. But as a freelance programmer it is quite common to have diffidence regarding the deployment of a ready application on client's servers, if their servers are not fully accessible by me (like a dedicated hosting server might be). Usually this is the most common case for not having CAP powering an application I'm creating. The problem is for the people that wish to use a shared web hostin environment. And of course Perl was always something found almost in any (Unix based) hosting environment, and from my experience cgi is quite usual to be enabled, mod_perl is not that uncommon environment and fastcgi and perperl are quite uncommon. So, even for the cgi case, I believe that the deployment of CAP on shared hosting environments can become quite difficult. Of course the case of having a working CAP in a shared hosting environment without even ssh access most of the times is prohibitive. I believe that it might be a good idea if feasible to have something (it might me some guidelines, procedures, software, don't know) that might ease the deployment. In the past I have made it to deploy a big CAP in a shared hosting environment with ssh, by installing many modules through cpan to users home directory. I can not tell that this was my best, since cpan access is not always available to user's (even when ssh access is available), incompatibilities with system modules and libraries may arrise and the scenario of moving the application to another server is troublesome. CAP is Perl and I do believe that Perl is portable, but CAPs are not easy to install or move in such environments. I've tried using PAR. I really thought that PAR would be ideal for the whole situation, since it would have self contained all the modules and the application that would ease the installation and deployment. I created all the necessary files, but the resulting packaged CAP was not working correctly giving quite strange errors. Have any of you managed to approach this problem in any effective way? I believe that a solution (any kind) that would ease the packaging and the deployment of CAP would be highly beneficial for CAP and it's users. In the ideal scenario CAP might have a helper tool, to ease the packaging and deployment of the application on servers (maybe by using PAR). There are cases where a a web server and Perl (even as cgi) is available and should be adequate for a CAP to work, but it's not. Regards, Giannis - 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] CAP::Dispatch params containing spaces?
Hello all...
I'm using CAP::Dispatch and I have a question. Do not know if this is by
design or a flaw, but I kind of need to use this...
When a URL contains the escaped space character, CAP::Dispatch returns
as a parameter only the part before the space character. Example:
for the URL: http://www.example.com/search/1/any/Sri%20Lanka/asc
I get only: 'Sri' back from $self-param('foo'); and not 'Sri Lanka'.
Don't know if this happens for any escaped character and not just the
space char.
Thank you,
Giannis
-
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::Dispatch params containing spaces?
You are right, there are other server side rewrite rules not written by
me neither visible to me...
But dispatch was getting a wrong URL.
Thank you...
Michael Peters wrote:
Giannis Economou wrote:
I've just noticed something even more insteresting!
It is not only that I get only half the string ('Sri' for 'Sri
Lanka'), but _all parameters after %20 are ignored_.
CAP::Dispatch Version 2.00_04.
mod_rewrite get's in the way and I'm using PersistentPerl for
persistency. URL handling happens after following this Directive:
RewriteRule ^(.*)$ /cgi-bin/app.pl/$1 [P,L,T=application/x-httpd-cgi]
(a second rewriting is active, so I need the [P] above.
So you are proxying the request to another machine host? What does your other
RewriteRule look like? I don't think it's Dispatch that's eating your URL,
it's
mod_rewrite. I bet if you look in the script that is using Dispatch and see
what
the full path info is ($ENV{PATH_INFO}) you'll see that Dispatch never even
sees
anything past the %20.
-
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?
I'm doing the following now, have you tried it?
Inside the runmode I want the login to happen:
sub another_runmode {
...
$self-query-param( -name = 'auth_usr_uname', value = $uname);
$self-query-param( -name = 'auth_usr_passwd', value = $passwd);
$self-authen-initialize;
...
}
the idea is, set the query params that Authen is looking for and then
call authen-initialize in the runmode.
Giannis
Simon Rees wrote:
Hi
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...
One idea I had for an enhancement to the plugin was to add a reinitialize
method which didn't check $self-{initialized} before checking the
credentials. If the credentials were valid the user would be logged in from
this point. I haven't checked through the code in detail to understand the
implications of this yet... does it sound like a good idea?
cheers, Simon
-
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] To many FormState keys in session?
Hello... Is it normal for the CAP::FormState to fill up my session with variables? Everytime a template (I'm using TT2) is loaded the FormState hook creates a new storage_key (even in views I do not use the FormState at all). Keys are reused only in cases where I pass the storage_key between requests. Thank you... Regards, Gianis - 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] Prevent entering specified running mode
Not sure I understand what you are looking for, but it seems to me like authorization. You might take a look at the CGI::Application::Authorization module at CPAN. With CAP::Authorization you can easily set up which runmodes can be accessed by which users (and you might also want to check CGI::Application::Authentication for authenticating the users in your app). Giannis Anthony Chee wrote: Hi, I would like to know if CGI::App has mechanism to prevent user entering specified running mode, for example, using the following link, HYPERLINK http://www.server.com/?rm=mode1http://www.server.com/?rm=mode1. Thanks. Regards, Anthony - 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] mod_perl + CAP::AutoRunmode not working
Ron Savage wrote: On Fri, 14 Apr 2006 16:57:23 +0300, Giannis Economou wrote: Hi Giannis Glad to hear you've found an explanation for (some of) your problems. instance script. Now I have: use Apache::Reload; However, I'm concerned by your use of Apache::Reload. I use it too, but it goes on httpd.conf, not in your instance script. Here's how I use it: PerlModule Apache::Reload PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadModules CGI::Application::Demo CGI::Application::Demo::* where the list of modules to be monitored can be as long as you want. Thank you Ron. I was doing the reload the wrong way indeed. Fixed that now. Don't know why, but reloading of modules seemed working even my (wrong) way, but now I've changed my .htaccess according to your message. I've also had to set an InitHandler to fix my $INC in .htaccess. Modules are reloaded right (tried to change something again) and changes are propagated immediately. CAP::AutoRunmode still not working. Regards, Giannis - 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] mod_perl + CAP::AutoRunmode not working
Ron Savage wrote: On Sat, 15 Apr 2006 12:40:22 +0300, Giannis Economou wrote: Giannis way, but now I've changed my .htaccess according to your message. .httpd.conf actually. .htaccess actually, because it's virtual hosting and I don't have access to httpd.conf. These directives are accepted in .htaccess (AllowOverride All in effect, no errors and reloading of altered modules working right). Giannis - 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] mod_perl + CAP::AutoRunmode not working
Hello... Just moved a C::A under mod_perl 2 and CAP::AutoRunmode is not working. Runmodes defined by CAP::AutoRunmode are not recognized. In tried to put or change the order of 'use' in the beginning of my instance script. Now I have: use Apache::Reload; use Apache::compat; use Class::DBI; use CGI::Application; use CGI::Application::Plugin::AutoRunmode; use CGI::Application::Dispatch; use Project::App; but nothing... The runmodes can not be found / seem not registered. In plain cgi and persistentperl runmodes are ok. Generally, Project::App is a MyCA::App is a MyCA::BaseApp is a C::A. I have override setup() in MyCA::BaseApp. Installed the AUTOLOAD there too (as a 'catch up' for not existing runmodes and this is what I always get regardless of the request). AUTOLOAD seems not related at all with the problem (and is not working even when commented out). Is this one confirmed as a bug, has anyone seen this in the past? Any ideas/workarounds? TIA, Giannis - 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] mod_perl + CAP::AutoRunmode not working
Michael Peters wrote: Giannis Economou wrote: Hello... Just moved a C::A under mod_perl 2 and CAP::AutoRunmode is not working. Runmodes defined by CAP::AutoRunmode are not recognized. In tried to put or change the order of 'use' in the beginning of my instance script. Now I have: use Apache::Reload; use Apache::compat; use Class::DBI; use CGI::Application; use CGI::Application::Plugin::AutoRunmode; use CGI::Application::Dispatch; Why are you use'ing C::A::Dispatch here? It's not meant to be used from inside of a C::A based module. It sits outside. The above code is in my instance script as I write in the sentence before the 'use' statements. It is not inside any C::A based module. Later on in this script there is a call to C::A::Dispatch() with the dispatch table. Also, could you show us your relevant mod_perl/Apache configuration? Are you running this under ModPerl::Registry or as a straight handler? C::A works fine under either approach, but the configuration is different. The whole site/app is running inside a virtual host (chrooted) and I don't have the freedom I would like (I can put Apache Directives in my .htaccess only but many things are not allowed, for example I can not add any PerlHandler). I'm running under ModPerl::Registry nothing more in the server's .conf. I was planning to run this under PersistentPerl, but it is not working right, perperl backend processes do not stop running as they should and if application sits idle for more that the Timeout option of perperl it stops responding. So I moved to mod_perl, but I want to make as little changes as possible to my initial application. Giannis - 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] mod_perl + CAP::AutoRunmode not working
Giannis Economou wrote: Just moved a C::A under mod_perl 2 and CAP::AutoRunmode is not working. Runmodes defined by CAP::AutoRunmode are not recognized. I was planning to run this under PersistentPerl, but it is not working right, perperl backend processes do not stop running as they should and if application sits idle for more that the Timeout option of perperl it stops responding. So I moved to mod_perl, but I want to make as little changes as possible to my initial application. Giannis Found out that there is already a bug filed for mod perl and CAP::AutoRunmode. I will use persistentperl for the time being. Found out that the problem was that perperl does not like overriding the DIE signal. Now it works. - 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] session no default expiration = no deletion ?
Hello... 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? Regards, Giannis - 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 ?
Thank you Cees.
I see I would expect this to be handled by CGI::Session though.
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 {} );
Also in the perldoc there is an example using find() for removing
objects that are 10+ days old.
Regards,
Giannis
Cees Hek wrote:
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 ?
Cees Hek wrote:
On 4/13/06, Giannis Economou [EMAIL PROTECTED] wrote:
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.
Of course you are right. CGI::Session-find can also be used as a
method in cron jobs (this is even mentioned in the perldoc) for efficiency.
My sessions now are on disk, but in my C::A's .conf file I can select
whether I want them on disk on in the db. By using the find() method, I
expect to keep the cron script small and intact, no matter how the C::A
is configured (db or files to store session) and manage to avoid making
changes to the sessions db table and staying db independent (same small
cron script for every driver, serializer and db system). Haven't tried
it though yet, we'll see.. It might not work as I expected (handling db
sessions, too) and as stated in the perldoc is still experimental.
Regards,
Giannis
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] large uploads handling
Michael Peters wrote:
Giannis Economou wrote:
Hello all...
Ok this is a weird problem I'm facing. I installed a webapp based on
CGI::Application that I created on the production server. My development
server runs debian, the prod. server freebsd. I'm using SpeedyCGI and
application is running fine in my dev. server. In the production server
everything is running ok except one thing:
When trying to CGI upload files that are larger than about 100-150 Kb I
always get a 500 error. Apache error log empty. Not even produced by my
script as it seems.
Do both servers have the same version of CGI.pm?
Yes! Line by line compared...
CGI.pm can also set the
limit of the POSTs using $CGI::POST_MAX. Although the docs say that if
it detects an upload larger than this amount it will produce an error.
$CGI:POST_MAX is set by me in CGI.pm. Also uploads enabled in CGI.pm and
tried /tmp and ~/tmp for saving temporary files.
Moreover, a simple CGI.pm script works without any problem (see below).
The same application under speedy on my dev. server handles these
uploads without problem. Tested uploads on prod. server without using my
application (just by using a simple CGI script I've created) and
everything went fine. I set my own TMPDIR for the uploads and in the
production server you can watch the upload as it is written in the
TMPDIR getting larger and suddently it stops getting bigger.
What size do the files end up being when they stop growing? Are they all
the same or similar sizes?
Uploading 800Kb size file.
Size of new file in TMPDIR (where the file ends up on server) varies.
From 80Kb to 320 Kb. Never more...
After a
while the browser gives the 500 error.
Production server is shared hosting and it seems they are using
setrlimit to put some limits on all processes, but I don't see anything
killed and I don't understand what limit could that be since all other
application requests are handled fine, except uploads that are larger
that the above mentioned size, only through my app.pl.
setrlimit can restrict processes based on simply the amount of CPU time
they use. Maybe since the request takes a long time to complete, you're
hitting some timeout on their part. Have you contacted the hosting
company about this?
Asked hosting company. The said about resources and setrlimit, but in
the logs nothings seems killed. No strict timeout limits by them.
Anyway, this is not the case (I mean timeouts), because a simple CGI.pm
script works always ok, regardless of the size of the upload! I created
something simple for testing, like:
use CGI qw(:all); print header; my $f = upload('form_file_field');
#print the file
...
post to this one and it works _always_ fine, regardless of the size of
the upload.
A perl script that doesn't even use CGI, (just dumps the STDIN) also
works always fine.
I'm using CGI::Application::Dispatch and mod_rewrite rules in a
.htaccess and I start thinking that maybe it is a complication by the
dispatcher in the way?
I don't think mod_rewrite or Dispatch have anything to do with this. I'm
pretty sure that they would both just ignore any POST data. Besides, by
the time CGI start's writing out the tmp files for the upload, both
mod_rewrite and Dispatch have long since been forgotten.
If Dispatch is forgotten then why don't I get any messages or error_log
or in any log (I've put some print messages, plus everything in the C::A
I use for logging) before the upload gets started? I've put print
messages just after the shebang of the instance script. Nothing.
Yesterday moved the application to a new server, linux based and it is
working without this strangeness. Guess I will never find out the reason
for this...
Thank you!
Giannis
-
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?
Cees Hek wrote:
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
Yes
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 app works correctly, since the eval captured the error and ignored it.
Cheers,
Cees
All explained now, thank you.
Giannis
-
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] questions on CGI::Application, Class::DBI::Loader
Hello...
James.Q.L wrote:
Hi, all
question
Hi,
I am new to C::A and Class::DBI. I have two questions during the learning
process.
1. In my C::A script, I have
$self-mode_param( path_info= 1 );
then i will request http://localhost/movie/945
where movie will be the run mode because of mode_param, but how do i get the
945? do i need to
manually parse path_info ?
Maybe you want to try CGI::Application::Dispatch..
This will allow you to easy setup those mappings you are asking, in a
very simple way:
and then in your 'movie' rm you will be able to fetch the movieid just as:
my $movie_id = $self-param('movieid');
2. I am trying to use Class::DBI::Loader. currently what i have is (simplified)
sub cgiapp_init {
my $self = shift;
my $loader = Class::DBI::Loader-new(
dsn = $self-config_param('database.data_source'),
options = { RaiseError = 1, PrintError = 1},
namespace = ToRest,
relationships = 1,
);
if ( $loader ) {
$self-{_To_Rest_Loader} = $loader;
} else {
$self-log-debug(dbi loader failed);
}
}
I know I would need to create a few table classes in Class::DBI way. but i
don't need it with
Class::DBI::Loader as it does for me. but i felt a bit clumsy to have the
$loader saved as
$self-{_To_Rest_Loader} then call $self-{_To_Rest_Loader}-find_class ..
is there a better way to do it?
Personally I don't think this is clumsy. I would also setup an accessor
to get my loader instance without having to access the hash directly:
sub get_loader {
my $self = shift;
return $self-{_To_Loader};
}
Another option:
I haven't used Class Loader, but looks like pretty static in its
functionality and maybe an alternative would be to use Class::Singleton
to subclass Class::DBI::Loader as a singleton and always get the same
instance of Class Loader when asking for a Loader by calling:
my $loader = MyLoader-instance();
Regards,
Giannis
thanks!
Qiang
-
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] large uploads handling
Hello all... Ok this is a weird problem I'm facing. I installed a webapp based on CGI::Application that I created on the production server. My development server runs debian, the prod. server freebsd. I'm using SpeedyCGI and application is running fine in my dev. server. In the production server everything is running ok except one thing: When trying to CGI upload files that are larger than about 100-150 Kb I always get a 500 error. Apache error log empty. Not even produced by my script as it seems. The same application under speedy on my dev. server handles these uploads without problem. Tested uploads on prod. server without using my application (just by using a simple CGI script I've created) and everything went fine. I set my own TMPDIR for the uploads and in the production server you can watch the upload as it is written in the TMPDIR getting larger and suddently it stops getting bigger. After a while the browser gives the 500 error. Production server is shared hosting and it seems they are using setrlimit to put some limits on all processes, but I don't see anything killed and I don't understand what limit could that be since all other application requests are handled fine, except uploads that are larger that the above mentioned size, only through my app.pl. I'm using CGI::Application::Dispatch and mod_rewrite rules in a .htaccess and I start thinking that maybe it is a complication by the dispatcher in the way? Also tried to substitute CGI with CGI::Simple, but got this bug: http://rt.cpan.org/Public/Bug/Display.html?id=14838 Has anyone faced similar problems in the past or has any ideas? TIA, Giannis - 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::Plugin::FormState and C::A::Dispatch ?
Michael Graham wrote:
Does anyone have used CGI::Application::Plugin::FormState together with
CGI::Application::Dispatch?
I do. At the moment, I'm using a custom subclass of
CGI::Application::Dispatch v1, but I hope to upgrade to version 2 soon.
Here's how I handle redirects:
$self-redirect(/step2/?cap_form_state=.$self-form_state-id );
So I'm just passing cap_form_state as a regular URL query parameter.
This works for me.
After successful validation of each form I use a call like:
return $self-redirect('/step2/' . $self-form_state-id);
to go to the next one, because CGI::Application::Dispatch is in use.
By C::A::Dispatch module, the 'cap_form_state' param is not set to the
$self-query object , but to $self-param
and after the redirection the new form's $self-query has a new random
string value for 'cap_form_state' param.
A call like:
$self-query-param('cap_form_state', $self-param('cap_form_state');
doesn't seem to work in the runmode (to late?)
I think this should work fine, as long as you take care to put this
value in the query object before your first call to $self-form_state.
The first time you call $self-form_state the plugin will try to fetch
the id from the query object using code like this:
my $storage_hash = $webapp-query-param('cap_form_state')
|| $webapp-query-url_param('cap_form_state');
Are you calling $self-form_state-config somewhere earlier in your
app (e.g. cgiapp_init or cgiapp_prerun)? If you are, then you need
to stuff the form state id in the query object before you do this.
And BTW, is it possible to pass hashrefs between forms, like:
$self-form_state-param('step1' = $valid_results_ref);
and retrieve in on the 'next' form? Or do I have to use something like
Storable.pm first on the hashref?
Anything you can store in the user's session should be safe to store in
a formstate param. So the only things you should avoid are objects,
which require special care when re-vivifying.
Michael
---
Michael Graham [EMAIL PROTECTED]
Michael thank you for your reply.
I did find out what was happening yesterday, after looking at
CAP::FormState source.
The problem (as you write) was that I was calling form_state-config in
the runmode prerun method, before setting the form state id to the query
object. Now fixed that and everything is working nice.
But now you made me really wonder what special care do objects need...
I was about to do that, it would be convenient for me to store instances
of Class::DBI into my session and re-vivifying them later on to write
them to the db.
Is there any suggested way to go for storing objects in session and have
them back solid as they were before serialization in our session?
Regards,
Giannis
-
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::Plugin::FormState and C::A::Dispatch ?
Perrin Harkins wrote: On Mon, 2006-04-03 at 00:38 +0300, Giannis Economou wrote: The id is a nice way to go, but what can someone do if we are talking about new records that get their ids from the database and C:DBI's create() method does not create any id until the database provides it. Class::DBI's crate() method immediately inserts the row and gets an ID. It is not possible to have a Class::DBI object without an ID. - Perrin It is possible to have a Class::DBI object without an id, before the insert really takes place. From Class::DBI perldoc: The |before_create| trigger is invoked directly after storing the supplied values into the new object and before inserting the record into the database. The object stored in $self may not have all the functionality of the final object after_creation, particularly if the database is going to be providing the primary key value. Giannis - 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] CAP::Plugin::FormState and C::A::Dispatch ?
Hi...
Does anyone have used CGI::Application::Plugin::FormState together with
CGI::Application::Dispatch?
I'm building a multiple steps registration (several forms) and I want to
save everything in the db at the final step/last form. In the in between
steps I thought using CAP::FormState to pass data submitted from
previous forms to the next one.
After successful validation of each form I use a call like:
return $self-redirect('/step2/' . $self-form_state-id);
to go to the next one, because CGI::Application::Dispatch is in use.
By C::A::Dispatch module, the 'cap_form_state' param is not set to the
$self-query object , but to $self-param
and after the redirection the new form's $self-query has a new random
string value for 'cap_form_state' param.
A call like:
$self-query-param('cap_form_state', $self-param('cap_form_state');
doesn't seem to work in the runmode (to late?)
And BTW, is it possible to pass hashrefs between forms, like:
$self-form_state-param('step1' = $valid_results_ref);
and retrieve in on the 'next' form? Or do I have to use something like
Storable.pm first on the hashref?
Regards,
Giannis
-
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] CGI::Uploader bug? (was: [cgiapp] VaildateRM with CGI::Uploader)
Giannis Economou wrote:
Hello all...
Has anyone use CAP::ValidateRM validating file uploads, together with
CGI::Uploader successfully?
Unfortunately I'm trying to make them work together but can't make it
right.
The problem is that the mime-type of the upload can not be determined
correctly by CGI::Upload.
Some source:
my ($results, $err_page) =
$self-check_rm('reg_services','_services_profile');
if ($err_page) { $self-log-debug(Found validation errors in
submission); return $err_page; }
my $valid = $results-valid;
my $u = CGI::Uploader-new( spec = { letter_file = {} },
updir_url =
$self-get_app_config('BaseURL') .'/externals/',
updir_path = $uploads_path,
dbh= $self-dbh,
query = $self-query,
up_table = 'uploads',
);
my $valid_after_ul = $u-store_uploads( $valid );
and in the validation profile:
constraint_methods = {
letter_file = [
file_format( mime_types
= [ 'application/pdf','application/msword' ] ),
file_max_bytes(1024000),
],
},
Update:
When commenting the constraint as follows:
constraint_methods = {
letter_file = [
#file_format( mime_types
= [ 'application/pdf','application/msword' ] ), #text/vnd.ms-word
file_max_bytes(1024000),
],
},
CGI::Upload is able to determine the mime type fine. But with the line:
file_format( mime_types = [ 'application/pdf','application/msword'
] ),
not commented, CGI::Upload can not determine the MIME type and always
inserts application/octet-stream with .bin extension in the database.
It seems like a bug? If both CGI::Upload and
Data::FormValidator::Constraints::Upload try to get the mime type,
Data::FormValidator::Constraints::Upload (as the first one) does it
successfully, but CGI::Upload fails afterwards.
Regards,
Giannis
-
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] VaildateRM with CGI::Uploader
Hello all...
Has anyone use CAP::ValidateRM validating file uploads, together with
CGI::Uploader successfully?
Unfortunately I'm trying to make them work together but can't make it right.
The problem is that the mime-type of the upload can not be determined
correctly by CGI::Upload.
Some source:
my ($results, $err_page) =
$self-check_rm('reg_services','_services_profile');
if ($err_page) { $self-log-debug(Found validation errors in
submission); return $err_page; }
my $valid = $results-valid;
my $u = CGI::Uploader-new( spec = { letter_file = {} },
updir_url =
$self-get_app_config('BaseURL') .'/externals/',
updir_path = $uploads_path,
dbh= $self-dbh,
query = $self-query,
up_table = 'uploads',
);
my $valid_after_ul = $u-store_uploads( $valid );
and in the validation profile:
constraint_methods = {
letter_file = [
file_format( mime_types
= [ 'application/pdf','application/msword' ] ), #text/vnd.ms-word
file_max_bytes(1024000),
],
},
I've read some posts that seem related to this here:
http://thread.gmane.org/gmane.comp.lang.perl.modules.cgi-appplication/3926
and tried to edit Upload.pm to do the following to the $fh in use:
my $fake_fh = $query-upload('filename');
my $fh = \*$fake_fh;
but no luck. Also tried the other proposed workarounds (like Acme::Damn)
but no...
And something related. By reading CGI::Uploader docs, I thought that the
following should work:
my $valid_after_ul = $u-store_uploads( $self-query-Vars );
but no, it is not.
I'm stuck... Please, has anyone did this correctly? I'm I missing
something or doing something wrong?
Regards,
Giannis
-
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] catch-all in CGI::Application::Dispatch
Hi...
I 've just used for the first time the CGI::Application::Dispatch module
(ver. 2.0) for a CAP I'm writting.
One thought. Wouldn't be nice to be able to provide a catch-all
dispatching runmode while using the dispatch table in case no other
entry of the table match?
Like having one more name value pair passed to the dispatch() method like:
no_match = { '/myapp/notfound/'},
which will be used if nothing else matches.
This will make it possible to provide custom alternatives to the 'Not
found 4xx' page generated by the CGI::Application::Dispatch itself.
Right now (correct me if I'm wrong) you can put rules like:
':foo?/'== {app = 'Myapp', rm ='notfound'},
':foo?/:bar?'== {app = 'Myapp', rm ='notfound'},
in the table, but one can not do that for all slashes that might be
present in the URL.
Regards,
Giannis
-
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] catch-all in CGI::Application::Dispatch
Jesse Erlbaum wrote:
Like having one more name value pair passed to the dispatch()
method like:
no_match = { '/myapp/notfound/'},
which will be used if nothing else matches.
There is a facility like this built directly into CGI::Application:
THE RUN MODE OF LAST RESORT: AUTOLOAD
If CGI::Application is asked to go to a run mode which doesn't exist it
will usually croak() with errors. If this is not your desired behavior,
it is possible to catch this exception by implementing a run mode with
the reserved name AUTOLOAD:
$self-run_modes(
AUTOLOAD = \catch_my_exception
);
I'm using the AUTOLOAD already. The AUTOLOAD is fine for non
existing runmodes.
But I think this is not enough for what I'm writing about: no entries at
all matching the in dispatch table of CGI::Application::Dispatch.
CGI::Application::Dispatch will not match any entry in the table for a
given request, so it will not instantiate any subclass of
CGI::Application (in which the AUTOLOAD might be defined).
The AUTOLOAD is ok to handle requests like:
/myapp/welcome/start
where there is no 'start' runmode in a Class named Welcome (which is a
CGI::Application subclass), but I'm taking about requests like:
/myapp/foo/start
where the Class Foo does not exist at all.
Regards,
Giannis
-
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] CGI::Application::Plugin::Authorization - perldoc mistake (v. 0.03)
Hi...
Just want to mention a mistake found on the documentation of
CGI::Application::Plugin::Authorization current version.
In the docs found here:
http://search.cpan.org/~ceeshek/CGI-Application-Plugin-Authorization-0.03/lib/CGI/Application/Plugin/Authorization.pm
there is this example:
# Configure Authorization (manages runmode authorization)
MyCGIApp-authz-config(
DRIVER = [ 'DBI',
DBH = $self-dbh,
TABLES = ['user', 'usergroup', 'group'],
JOIN_ON = 'user.id = usergroup.user_id AND usergroup.group_id =
group.id',
CONSTRAINTS = {
'user.name' = '__USERNAME__',
'group.name' = '__GROUP__',
}
],
);
which in not working right.
For this example to work properly, one should see the documentation of
CGI::Application::Plugin::Authorization::Driver::DBI
(http://search.cpan.org/~ceeshek/CGI-Application-Plugin-Authorization-0.03/lib/CGI/Application/Plugin/Authorization/Driver/DBI.pm)
The correction can be:
# Configure Authorization (manages runmode authorization)
MyCGIApp-authz-config(
DRIVER = [ 'DBI',
DBH = $self-dbh,
TABLES = ['user', 'usergroup', 'group'],
JOIN_ON = 'user.id = usergroup.user_id AND usergroup.group_id =
group.id',
USERNAME= 'user.name',
CONSTRAINTS = {
'group.name' = '__PARAM_1__',
}
],
);
Regards,
Giannis Economou
-
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] CAP Application Design suggestion
Hi... I came up with the a specific design about an application I'm writing using CGI::Application. Here is an example: MyBaseAppis-a CGI:App MyAppis-a MyBaseApp Carsis-a MyApp Airplanes is-a MyApp Both Cars and Airplanes implement a runmode named: 'registration' I want to be able to call the right 'registration' runmode, according to one query param (for example, 'type') that user requests. Example the http://www.example.com/app.pl?rm=registrationtype=car; to be handled by the Cars 'registration' runmode. I thought to do that in app.pl script (the instantiation script): 1. Use plain CGI to check for the 'type' query parameter 2. Do a simple dispatch like: my $app = undef; $app = Cars-new() if $type eq car; $app = Planes-new() if $type eq planes; $app-run(); I'm wondering if they are better ways to do the above (maybe inside a CAP, without using the plain CGI for checking the 'type' param). Any suggestions or ideas (always for a persistent environment like mod_perl) are welcome... Regards, Giannis - 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 Application Design suggestion
Michael Peters wrote: Giannis Economou wrote: MyBaseAppis-a CGI:App MyAppis-a MyBaseApp You don't need an intermediar MyApp. Just have MyBaseApp and have Cars and Airplanes inherity from that. It's better for me with the intermediate MyApp. Having those 2 steps in extending CAP (one in MyBaseApp and one in MyApp) suits me better for future reusability (for example, only basic configuration and initialization but no runmodes definitions at all in MyBaseApp and must of the times to be there runmodes in MyApp). Carsis-a MyApp Airplanes is-a MyApp Both Cars and Airplanes implement a runmode named: 'registration' I want to be able to call the right 'registration' runmode, according to one query param (for example, 'type') that user requests. Example the http://www.example.com/app.pl?rm=registrationtype=car; to be handled by the Cars 'registration' runmode. I thought to do that in app.pl script (the instantiation script): 1. Use plain CGI to check for the 'type' query parameter 2. Do a simple dispatch like: my $app = undef; $app = Cars-new() if $type eq car; $app = Planes-new() if $type eq planes; $app-run(); I'm wondering if they are better ways to do the above (maybe inside a CAP, without using the plain CGI for checking the 'type' param). Any suggestions or ideas (always for a persistent environment like mod_perl) are welcome... Use CGI::Application::Dispatch (use the 2.0 version which is still labled 'development' but which I've been using in production just fine) so that your URLs can look something like (under normal CGI) /app.pl/car/registration /app.pl/airplane/registration This kind of mapping is so common in CGI::Application::Dispatch that you wouldn't even need your own custom dispatch table to deal with it. Exactly what I was looking for and even better, at least by your description. Will go to check it out immediately! Thank you! 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]
[cgiapp] Strange Problem with CAP::Authentication and CAP::Session?
I'm writing an application using the CAP::Plugins:
DBH, Session, Authentication, AutoRunmode, TT
and the whole day I'm really stuck with Module bugs (is that luck or
not?) and now something seems quite strange, so please help if you may...
About the bugs seen:
Some hours ago I've started by using in CGI_SESSION_OPTIONS while
initializing CAP::Session (in this order):
- driver:mysql;serializer:Storable
but I've got this bug
http://rt.cpan.org/Public/Bug/Display.html?id=17541 (DESTROY created
new reference to dead object 'CGI::Session' during global destruction.)
and I've found out that while trying to flush() data to storage there
was no DBI Handle set (that was happening right before the fatal error
which is the bug above).
Pitty, because I wanted to use the DB for the sessions.
- driver:file;serializer:Storable
Ok.. This gave me this bug
http://rt.cpan.org/Public/Bug/Display.html?id=7575 (Child died:
Storable binary image v20 more recent than I am) and I got over that
by using the Freezethaw serializer, which is working.
- Now, I've switched to driver:file; for testing (to view file
contents) and here comes the strangeness...
I'm able to properly use sessions in my app. I've set sessions, read
sessions, examined the cookie in browser and the files created in fs by
the CGI::Session module. Contents in fs files are properly updated and
cookie with session_id is properly sent.
The problem is when CAP::Authentication comes in! Everything is working
right when using the 'Cookie' STORE, but when switching to the 'Session'
STORE Authentication is NOT working (I repeat CAP::Session by itself is
tested and working).
I've put some debug messages into
.../CGI/Application/Plugin/Authentication/Store/Session.pm in save()
method to see what's happening. Things seemed ok.
sub save {
my $session = $self-_session;
while (my ($param, $value) = each %items) {
my $key = _names_to_keys($param);
$session-param( $key = $value );
}
...
}
Using Data::Dumper, I 've got BEFORE the $session-param() calls of the
above method (CAP::Authentication::Store::Session::save):
'_CLAIMED_ID' = 'b504e8434f',
'_DATA' = {
'_SESSION_ETIME' = 1200,
'_SESSION_ID' =
'b504e8434f',
'_SESSION_ATIME' = 1143230211,
'_SESSION_REMOTE_ADDR' = '192.168.3.2',
'_SESSION_EXPIRE_LIST' = {},
'_SESSION_CTIME' = 1143230174
and AFTER the calls:
'_DATA' = {
'AUTH_LAST_ACCESS' = 1143230211,
'_SESSION_ETIME' = 1200,
'_SESSION_ID' =
'b504e8434f.',
'AUTH_LAST_LOGIN' = 1143230211,
'_SESSION_REMOTE_ADDR' = '192.168.3.2',
'_SESSION_CTIME' = 1143230174,
'_SESSION_ATIME' = 1143230211,
'AUTH_USERNAME' = 'test',
'AUTH_LOGIN_ATTEMPTS' = 0,
'_SESSION_EXPIRE_LIST' = {}
},
but these updated data NEVER reach the file on filesystem that keeps the
session, so user in not logged in.
It is starting getting disappointing...
Some source code:
use base 'CGI::Application';
use CGI::Application::Plugin::DBH (qw/dbh/); #init in instance script
use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Authentication;
use CGI::Application::Plugin::AutoRunmode;
use CGI::Application::Plugin::TT;
sub cgiapp_init {
my $self = shift;
#init auth subsystem
$self-authen-config(
DRIVER = [ 'DBI',
TABLE = 'usersinfo',
CONSTRAINTS = {
'usersinfo.uname' = '__CREDENTIAL_1__',
'MD5_base64:salted_pass:usersinfo.passwd' = '__CREDENTIAL_2__'
},
FILTERS = { salted_pass = sub {
$self-salted_pass(shift,shift) } },
],
LOGIN_RUNMODE = 'login',
STORE = 'Session',
POST_LOGIN_URL = $CONFIG-GetBaseURL() . '/app.pl?rm=user_console',
LOGOUT_RUNMODE = 'logout',
CREDENTIALS = [ 'auth_usr_uname', 'auth_usr_passwd' ], #form
fields for auth
LOGIN_SESSION_TIMEOUT = {
IDLE_FOR = '30m',
EVERY= '1d',
}
);
#init our session
$CGI::Session::NAME = $CONFIG-GetAppName();
$self-session_config(
CGI_SESSION_OPTIONS = [ driver:File;, $self-query, {
Directory = $CONFIG-GetSessionDir() } ],
DEFAULT_EXPIRY = '+20m',
COOKIE_PARAMS = { -path= '/', },
SEND_COOKIE = 1,
) or die($@);
}
So to summarize, CAP::Session is working (with a File driver and not
Storable serializer) and CAP::Authentication is working with Cookie
STORE. I wanted Session STORE in
