Re: Help wanted with locations / configuration
On Tuesday 09 September 2003 11:16, Steve Hay wrote: Those were actually my very frist ideas, but I decided that I prefer to have all the URL's to begin with /myproject. I don't necessarily require that URL to be related to the filesystem structure, but I just want all the URL's (dynamic and static) to begin the same. I have achieved that using the configuration Perrin suggested. The prefix (/myproject) is a parameter of the configuration of the application called apache_location_root, and the config script fills a mod_perl.conf.tt2 like this: Alias [% apache_location_root %]/views [% prj_root %]/www/htdocs/views Alias [% apache_location_root %]/images [% prj_root %]/www/htdocs/images Alias [% apache_location_root %]/scripts [% prj_root %]/www/htdocs/scripts Alias [% apache_location_root %]/styles [% prj_root %]/www/htdocs/styles Location [% apache_location_root %] # Nothing to do with the filesystem, just handlers available in @INC. /Location In our case the motivation for that is that we don't know whether our application will run in its own Apache server, so you can hard-code that stuff, or will need to be added to an already functioning Apache. -- fxn
Re: Apache::Session and pnotes
On Tuesday 02 September 2003 07:46, you wrote:
(I am sorry I am not replying to the actual email, but to a forwarded
copy from my desktop at home.)
It seems, however, that Apache::Session objects stop being stored
when I put the session in pnotes() with a code analogous to this:
Can you tell us more about the problem is? What do you see when you
take the session hash back out of pnotes?
I have dumped the hash in a content handler and it seems to be OK.
my $r = Apache::Request-instance(shift);
No need to involve Apache::Request just for this. Your handler
should be getting $r passed to it.
Apache::Request is used because the authenticator handles login via
param(), and more handlers need the parameters afterwards.
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle = $class-dbh(), Commit = 1};
$r-pnotes(session = \%session);
Show us the code you use to get it back.
When a request is received the session id is retrieved from a cookie.
The schema (with some irrelevant checks removed) would be this:
my %cookies = Apache::Cookie-fetch;
my $cookie = $cookies{COOKIE_NAME()};
my $session_id = $cookie-value;
my %session;
eval {
tie %session, 'Apache::Session::Oracle', $session_id,
{Handle = $class-dbh(), Commit = 1};
};
The eval block is there now because it seems Apache::Session::Oracle
dies if it cannot retrieve the session.
That code works all right if \%session is not stored in pnotes(), but if
it is put the session is not read back from the database and I have
checked from a database client that there is no new row written.
I am doing basic stuff with this, so if it sounds strange it is likely
that I doing something wrong.
-- fxn
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
On Tuesday 02 September 2003 07:28, Perrin Harkins wrote: Sorry, I don't understand what you're saying here. What you should be doing is fetching the session once, putting it in pnotes, and getting it from pnotes for the rest of the request. I am sorry, I'll try to reword it. Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. When later that very user comes back to the website with a valid session id in the cookie, one reads the session from the database. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Is it better now? -- fxn -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Session and pnotes
I am trying to retrieve/create an Apache::Session object for a given
user in the authentication phase, so the following handlers have them
available via pnotes. Sessions are stored in an Oracle database.
It seems, however, that Apache::Session objects stop being stored when I
put the session in pnotes() with a code analogous to this:
my $r = Apache::Request-instance(shift);
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle = $class-dbh(), Commit = 1};
$r-pnotes(session = \%session);
Is there any gotcha regarding the kind of objects that can be passed
with pnotes? Or do you know what can be happening anyway if not?
-- fxn
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 20:26, Christopher Grau wrote: On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the test is performed by Location anyway. Now that I understand what happens I will try to figure out in the docs when $r-content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 19:53, Christopher Grau wrote: Are you sure the content-type is text/html? Since you have your own Location handler, Apache is probably using the value from the DefaultType directive which, I think, defaults to text/plain when Apache is installed. That's it, $r-content_type ne 'text/html'; succeeds because $r-content_type is undef, so we return DECLINED and the default content handler is run AFAICT. DefaultType is text/plain in httpd.conf, why that method returns undef? To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? -- fxn
help on setting up a PerlFixupHandler
I am trying to write a Hello World!-like set up involving a
PerlFixupHandler but cannot get it to work. What I want to
accomplish is:
1. Configure Dispatcher.pm as a PerlFixupHandler for
http://localhost/admin.
2. Let Dispatcher.pm set ContentHandler.pm as the content
handler for that request.
3. Have ContentHandler.pm called in the corresponding phase.
but in the Apache log I see:
File does not exist: /home/fxn/prj/bw/buscawap/www/htdocs/admin
so looks like Apache is running the default handler looking under the
document root, which is /home/fxn/prj/bw/buscawap/www/htdocs.
This is mod_perl.conf:
# Just change @INC
PerlRequire /home/fxn/prj/bw/buscawap/etc/startup.pl
PerlModule Dispatcher
Location /admin
PerlFixupHandler Dispatcher
/Location
Dispatcher.pm:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
1;
ContentHandler.pm:
package ContentHandler;
use Apache::Constants qw(OK);
sub handler {
my $r = shift;
$r-send_http_header('text/html');
$r-print('htmlheadtitleFoo/title/headbodyFoo/body/html');
return OK;
}
1;
What am I missing?
-- fxn
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 18:29, Geoffrey Young wrote:
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase
you need to do two things - tell apache that mod_perl is in charge,
and tell mod_perl which Perl handler it should use. you've done the
latter. for the former, use $r-handler('perl-script'), which is
analogous to SetHandler perl-script that you would ordinarily see for
a mod_perl setup.
Thank you!
I tried to add that line to the Dispatcher:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-handler('perl-script');
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
1;
without luck however, keeps on looking under the document root
for /admin. Should that change be enough?
-- fxn
Re: help on setting up a PerlFixupHandler
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
-- fxn
advice on implementing a controller manager
I am writing an application following MVC with Perl Apache modules and the Template Toolkit. Apache is 1.x. I would like to have just one entry point to the application, which would play the role of someone who sets everything necessary up and forwards the actual request to a selected handler. From what I have read, looks like implementing that controller as a PerlFixupHandler which would use push_handlers() and pass things via pnotes() would be fine, but I am not experienced in mod_perl. Would you suggest a different approach? fxn -- s;$;Barcelona Perl Mongers;;$/=$||gaudi||3;map$,+=(split//)*(-1)**$|++, (split)[.11_09,1.714];$.=$!!~m~erce~;$=y~catalunya~~,$;=y~rambles~~,$* =$/^$.;$:=$.+length,[EMAIL PROTECTED]/**$*%$:,$%=$/*$-$*;print+chr($_0xA?$. .$[$_:m:^$.:?$.$_:$_)for($**($**$%-$//$/),$%-$*,$,*$/,$***$***$*,$* **$,,$[EMAIL PROTECTED]/,$**$,,$;,$***$***$*,$***$*,$.,$**$,$***$,,$***$***$** $,,$.,$*$*,$+$.,$***$,,$,-$.,$[EMAIL PROTECTED]/,$;*$/**$*,$,$.,[EMAIL PROTECTED])
Re: problem building libapreq on Solaris
On Saturday 14 June 2003 20:54, Ged Haywood wrote: On Fri, 13 Jun 2003, Xavier Noria wrote: Hello, I've just compiled Apache 1.3.27 with mod_perl 1.27 from their tarballs on Solaris. perl is 5.8.0 packaged for Solaris. The installation of libapreq with cpan(1) stops here: [snip] t/httpd -f `pwd`/t/httpd.conf /bin/sh: t/httpd: not found [snip] Looks like it's taking t/httpd instead of /usr/local/apache/bin/httpd, Don't know if there's anyone who actually knows what's going on here but I thought you'd just like to hear from somebody. :) [snip] You could try a soft link from there to the real httpd - I have no idea if something else will then fail. Thank you very much, the symlink worked for libapreq-1.1. I first tried to install the just announced 1.2-rc2, but make test failed: PERL_DL_NONLAZY=1 /usr/local/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/*t/*.t does not exist FAILED--1 test script could be run, alas--no output ever seen make: *** [test_dynamic] Error 2 I have a full typescript file and subscribed to the dev mailing list to report this, I'll send it right away when I receive the confirmation of the subscription from the list manager. Thank you all! fxn -- $_=q;Barcelona Perl Mongers;,$/=y,gaudi,,,;map$,+=(split//)*(-1)**$e++, (split)[.11_09,1.714];$.=qq~~!~m~erce~;$=y,catalunya,,,$;=y,rambles,,, $*=$/^$.;$:=$.+length,[EMAIL PROTECTED]/**$*%$:,$%=$/*$-$*;print+chr($_012? 10$_:/^1/?1$_:$_)for($**($**$%-$//$/),$%-$*,$,*$/,$***$***$*,$***$, ,$[EMAIL PROTECTED]/,$**$,,$;,$***$***$*,$***$*,$.,$**$,$***$,,$***$***$**$,= ~~$.,$*$*,$***$/,$***$,,$,-$.,$[EMAIL PROTECTED]/,$;*$/**$*,$,$.,[EMAIL PROTECTED])
Re: problem building libapreq on Solaris
On Saturday 14 June 2003 20:54, Ged Haywood wrote: Don't know if there's anyone who actually knows what's going on here but I thought you'd just like to hear from somebody. :) Sure, thank you :-). This is a wild stab in the dark. Guessing that the libapreq installation scripts are assuming that you're building a new Apache/mod_perl, you might in that case be expected to have a copy of the a httpd in the t directory. When you run 'make test' during an Apache build that's where the binary will be, temporarily. You could try a soft link from there to the real httpd - I have no idea if something else will then fail. OK. I will try to install libapreq-1.2 next Monday at work. If it does not work will try the soft link. In any case I'll say something here to let you know how it went. You know that your mod_perl and your Perl should really be compiled with the same compiler? I always think it's best to build it yourself to be sure. Hm... I didn't remember that. I installed perl using its package for Solaris. Maybe I'd better get the tarball to be sure. Thank you! -- fxn -- fxn
problem building libapreq on Solaris
Hello, I've just compiled Apache 1.3.27 with mod_perl 1.27 from their tarballs on Solaris. perl is 5.8.0 packaged for Solaris. The installation of libapreq with cpan(1) stops here: Running make test make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf /bin/sh: t/httpd: not found make: *** [start_httpd] Error 1 /usr/local/bin/make test -- NOT OK Looks like it's taking t/httpd instead of /usr/local/apache/bin/httpd, though I entered that full path to httpd in a previous prompt. With similar settings I've just smoothly installed libapreq on Debian, do you know what can be happening? -- fxn
Re: Propogating Errors / E-Toys
On Sun, 30 Jun 2002 12:58:08 -0400 Perrin Harkins [EMAIL PROTECTED] wrote: : Well, naturally the answer is it depends. Most database errors can't : be gracefully recovered from, so we would let them propagate up. If it : was possible for a database error to be caused by user input (say, a : duplicate login name) that would need to be caught and handled. It : would also be caught if any special cleanup of non-database resources : was needed. Excellent message, thank you for sharing those experiences once again! I remember the article has a comment regarding a gotcha of the Error module that causes memory leaks, but you didn't go into details there. I took note of that and am using eval instead of the try/catch syntax since I do not understand what the problem is and cannot program avoiding it for sure... I would appreciate very much if you could give further details (maybe a pointer somewhere) on what origines the leak and which was your style writing try/catch blocks once aware of the problem. Thanks, and best regards from template Barcelona, -- fxn
[OT] what drives Amazon?
Does anybody know which is the technology behind Amazon? -- fxn
Re: separating C from V in MVC
On Fri, 14 Jun 2002 10:34:47 +0100 (BST) Mark Fowler [EMAIL PROTECTED] wrote: : On Fri, 14 Jun 2002, Nigel Hamilton wrote: : : Generally I try to minimise the layers/tiers/abstraction between : the front-end and the database - for me OO/SQL abstraction is something : akin to 'GOTO considered harmful'. : : The advantage of this is that we get better reuse in out of our SQL when : we need the same function called from many places, and we can reuse the : same SQL on similar tables/databases for different runs. Another : advantage is that should we ever want to change the database all our SQL : is in a few modules and we can make sure that we change all our SQL. Another useful thing is that you can implement some cache mechanism there, in one place, and this is transparent to clients who just keep on calling, say, $category_factory-read_category_tree(), no matter whether the tree is actually fetched from the database or from shared memory. -- fxn
Re: MVC advice..?
On Wed, 29 May 2002 09:22:00 -0400
Aaron Ross [EMAIL PROTECTED] wrote:
: Is there a neat way of dynamically loading in the appropriate control
: subclass? Something proven and widely used.
:
: For what it's worth, I use the eval trick too. Although it may seem a
: little clunky, I believe it is proven and widely used. The DBI.pm
: module uses code like this to load in the DBD drivers:
:
: my $driver_class = DBD::$driver;
: eval package DBI::_firesafe; require $driver_class;
I wonder, why do you program such a central module that dynamic? Why
do you chose that approach instead of this one?
package Dispatcher;
use Controller1;
# ...
use ControllerN;
sub handler {
my $r = Apache::Request-new(shift);
my $ctl = $r-param('ctl');
return Controller1::handler($r) if $ctl = 'login';
# ...
return ControllerN::handler($r) if $ctl = 'show_cart';
return SERVER_ERROR;
}
-- fxn
Re: Memory Leaks
On Mon, 20 May 2002 16:23:40 -0500 Gregory Matthews [EMAIL PROTECTED] wrote: : Unfortunately, we only have one machine. If we did employ the cron job as : a clean-up utility once per day, wouldn't the potential impact of a site : being unavailable only be for a few seconds (until Apache restarted)? ... provided one is not using memory as unique storage for sessions or some other data maybe? -- fxn
Re: Monitoring the processes
On Mon, 20 May 2002 15:50:35 -0500 Gregory Matthews [EMAIL PROTECTED] wrote: : Thanks to everyone for the great input on Memory Leaks. Now that I have a : good starting point for tracking down the problem, when I TEST for leaks, : or simply check for a continued increase in server memory usage, how do I : go about monitoring the processes growth? I have not used it, but it seems Apache::Status can help, see the documentation about the option StatusTerseSizeMainSummary. -- fxn
Re: Memory Leaks
On Sun, 19 May 2002 23:34:24 -0400
Perrin Harkins [EMAIL PROTECTED] wrote:
: Leaks are caused by circular references, the string form of eval (at
: least it used to leak a little), nested closures (sometimes created
: accidentally with the Error module)
I am using the Error module in my current project, what kind of
constructs should one avoid? Is this safe?
my $um = UserManager-new;
# ...
try {
$um-write_user($user);
$um-dbh-commit;
} catch Exception::DB with {
my $e = shift;
debug Exception: $e;
$um-dbh-rollback;
};
-- fxn
Re: Memory Leaks
On Mon, 20 May 2002 10:15:02 +0100 (BST)
Matt Sergeant [EMAIL PROTECTED] wrote:
: my $um = UserManager-new;
: # ...
: try {
: $um-write_user($user);
: $um-dbh-commit;
: } catch Exception::DB with {
: my $e = shift;
: debug Exception: $e;
: $um-dbh-rollback;
: };
:
: No. $um is caught in a closure, which could potentially leak.
Wow, thank you, I have that pattern repeated in the code many times.
That is the way I would write that try/catch in Java, where you need to
have $um in the scope of the try and the catch blocks, what is the right
way to write that in Perl/Error.pm?
-- fxn
Re: [OT] Refs don't work, like I want
On Fri, 17 May 2002 17:10:53 +0300 (EEST)
Viljo Marrandi [EMAIL PROTECTED] wrote:
: $vars-{'key2'} = value of second key;
The hash $vars points to has a key named key2.
: $vars = {
: xxx = AAA,
: yyy = BBB,
: zzz = CCC,
: };
Now you change the reference stored in $var. It points to an entirely
new hash, whose keys are xxx, yyy and zzz.
: $vars-{'key1'} = value of first key;
Here you add the key key1 to the hash $vars points to.
: Problem is, that value of key2 is lost after I set values to xxx, yyy and
: zzz, but key1 is ok.
$vars contains a reference to a hash that has nothing to do with the
first one, you didn't create a key named key2 in that hash.
-- fxn
Re: Desperate for ePerl fix on 5.6.1
On Thu, 9 May 2002 04:29:43 +0100 Nick Barton [EMAIL PROTECTED] wrote: : I've installed ePerl on FreeBSD 4.5-Stable and have Perl 5.6.1 i386-freebsd. : Running ePerl standalone it reports 'Can't locate loadable object for module : Parse::ePerl' i.e. can't find the C extension. : : What I need to do to the Makefile for eperl to get it to run with perl 5.6.1 : (or 0) Have you installed the ePerl port? It's under /usr/ports/lang/eperl? -- fxn
convention on logging?
I am writing a web application that uses Apache modules and core classes in a MVC style. AFAICT using $r-log-debug() is the standard way to print debug messages in Apache modules, but which would be the right way to print debug messages in the core classes provided both types of modules are going to run together? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Mon, 06 May 2002 10:04:28 -0400 Fran Fabrizio [EMAIL PROTECTED] wrote: : Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key : file has to be set before the PerlModule directive, it is a bug in the : documentation. : : Except it doesn't really, because it works fine for me. =) : : I compiled mod_perl static, I tend to avoid DSO if possible. The Eagle book says (page 58): Apache processes the configuration directives on a first-come, first-serve basis, so in certain cases, the order in which directives appear is important. So Apache passes PerlModule and PerlSetVar to mod_perl as it finds it in its configuration file. If mod_perl loaded modules as they come by means of PerlModule that would explain why variables set with PerlSetVar after that directive are not seen by the very module at loading time. As that seems to be the behaviour in my static mod_perl and Jacob Davies said he had to change the documentation (and he knows more mod_perl than I for sure), I don't understand why the order does not matter in your machine. Do we have the same version of the module (v1.18)? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Fri, 3 May 2002 22:02:18 -0700 Jim Helm [EMAIL PROTECTED] wrote: : I was having the exact same problem 2 days ago... Could it be a : difference in static vs. dso? I'm running mod_perl as a dso - how about : you two? I compiled httpd. Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key file has to be set before the PerlModule directive, it is a bug in the documentation. -- fxn
Re: problems setting up Apache::AuthCookieDBI
On Thu, 02 May 2002 15:22:59 -0400 Fran Fabrizio [EMAIL PROTECTED] wrote: : Do you have this in httpd.conf (or mod_perl.conf) : : PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key : : ? I have all mod_perl-related things in mod_perl.conf, and httpd.conf ends with this line: Include /home/fxn/prj/bw/buscawap/etc/mod_perl.conf Could that matter? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Thu, 2 May 2002 20:10:15 +0200
F. Xavier Noria [EMAIL PROTECTED] wrote:
: I am having problems configuring Apache::AuthCookieDBI and am a bit
: lost, since it seems there is something wrong with the secret key
: file I cannot see, I attach below the configuration in case it can
: help. I have checked the permissions of the file (the server runs
: in by box as fxn):
The problem, it seems, was that I was setting the variables used by the
module _after_ loading it, as in the example of its manual page:
PerlModule Apache::AuthCookieDBI
PerlSetVar BuscaWAPPath /
PerlSetVar BuscaWAPLoginScript /cgi/login.pl
# These must be set
PerlSetVar BuscaWAPDBI_DSN dbi:Oracle:BW_CATALOG
PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key
Apache::AuthCookieDBI reads its config variables in a BEGIN block. I
inserted a trace there and keys %{ Apache-server-dir_config() };
returned no variable set via PerlSetVar after that PerlModule directive.
So the hash %SECRET_KEYS, initialized there, had no entries.
Moreover, when I tried to access a protected URL as localhost/docs I was
redirected to /cgi/login.pl as configured (as you see, after PerlModule
as well), which confused me. I suppose this is so because the module
sees the variable at runtime, where the config file has been already
fully read.
Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile
has solved the problem. I am doing something wrong or the example in the
manual page would need to be modified?
-- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Fri, 03 May 2002 09:09:08 -0400
Fran Fabrizio [EMAIL PROTECTED] wrote:
:
:
: Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile
: has solved the problem. I am doing something wrong or the example in the
: manual page would need to be modified?
:
: That's odd, I load my module first before setting the secret key (or any
: of the other variables) and it works fine for me.
If the module was loaded when the server sees the PerlModule directive
I think this code from Apache::AuthCookieDBI (version 1.18) implies that
variable in particular needs to be set before:
#===
# S E R V E R S T A R T I N I T I A L I Z A T I O N
#===
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache-server-dir_config() };
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache-server-dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, $keyfile ) ) {
Apache::log_error( Could not open keyfile for $auth_name in
file $keyfile );
} else {
Apache::warn(Adding key for realm $auth_name);
$SECRET_KEYS{ $auth_name } = KEY;
close KEY;
}
}
}
Does the server load the module that way?
-- fxn
problems setting up Apache::AuthCookieDBI
I am having problems configuring Apache::AuthCookieDBI and am a bit lost, since it seems there is something wrong with the secret key file I cannot see, I attach below the configuration in case it can help. I have checked the permissions of the file (the server runs in by box as fxn): $ ls -la /home/fxn/prj/bw/buscawap/etc/auth.key -rw---1 fxn12 May 2 19:20 /home/fxn/prj/bw/buscawap/etc/auth.key If I request /docs these messages appear in error_log: [Thu May 2 20:07:19 2002] [error] access to /login failed for 127.0.0.1, reason: Apache::AuthCookieDBI: didn't have the secret key for auth realm Busc aWAP [Thu May 2 20:07:21 2002] [error] access to /docs failed for 127.0.0.1, reason: Apache::AuthCookieDBI: didn't the secret key from for auth realm Busca WAP Any hint on what could I be doing wrong? -- fxn PerlModule Apache::AuthCookieDBI PerlSetVar BuscaWAPPath / PerlSetVar BuscaWAPLoginScript /cgi/login.pl # These must be set PerlSetVar BuscaWAPDBI_DSN dbi:Oracle:BW_CATALOG PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key # These are optional, the module sets sensible defaults. PerlSetVar BuscaWAPDBI_Userwap PerlSetVar BuscaWAPDBI_PasswordX PerlSetVar BuscaWAPDBI_UsersTable view_active_users PerlSetVar BuscaWAPDBI_UserField login PerlSetVar BuscaWAPDBI_PasswordField password PerlSetVar BuscaWAPDBI_CryptType none PerlSetVar BuscaWAPDBI_GroupsTable view_active_users PerlSetVar BuscaWAPDBI_GroupField rol PerlSetVar BuscaWAPDBI_GroupUserField login PerlSetVar BuscaWAPDBI_EncryptionType none PerlSetVar BuscaWAPDBI_SessionLifetime 00-24-00-00 Location /login AuthTypeApache::AuthCookieDBI AuthNameBuscaWAP SetHandler perl-script PerlHandler Apache::AuthCookieDBI-login /Location Alias /cgi /home/fxn/prj/bw/buscawap/www/cgi/ PerlModule Apache::Registry Location /cgi SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI /Location Location /docs AuthType Apache::AuthCookieDBI AuthName BuscaWAP PerlAuthenHandler Apache::AuthCookieDBI-authenticate PerlAuthzHandler Apache::AuthCookieDBI-authorize require valid-user SetHandlerperl-script PerlHandler BuscaWAP::Apache::Docs /Location
Re: problems setting up Apache::AuthCookieDBI
On Thu, 02 May 2002 20:24:10 +0200 Per Einar Ellefsen [EMAIL PROTECTED] wrote: : At 20:10 02.05.2002, F.Xavier Noria wrote: : PerlModule Apache::AuthCookieDBI : : PerlSetVar BuscaWAPPath / : PerlSetVar BuscaWAPLoginScript /cgi/login.pl : : # These must be set : PerlSetVar BuscaWAPDBI_DSN dbi:Oracle:BW_CATALOG : PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key : : Have you tried inserting these into the respective Location sections? I'm : not sure, but I think PerlSetVars aren't merged into location-specific : configuration, so they might not actually be caught by Apache::AuthCookieDBI I guess this is not the problem since /cgi/login.pl gets run by the module and is configured the same way. Thank you anyway! -- fxn
Re: Client capabilities
On Tue, 30 Apr 2002 16:26:00 +0400 Mike V. Andreev [EMAIL PROTECTED] wrote: : On Tue, 30 Apr 2002 13:00:33 +0100 : Simon Oliver [EMAIL PROTECTED] wrote: : : SO The main problem is that a client can be modified from the standard : SO install to prevent JavaScript, StyleSheets, Images, etc and there is no : SO way to detect this server side. : : (and some text-based browsers can be configured to use external program : to show images on user request [links for example] ) w3m renders images indeed :-). -- fxn
Basic usage of Apache::Session::Oracle
If I understand it correctly, Apache::Session::Oracle uses a table called sessions with at least two columns, one called id, of type varchar2(32), and another called a_session, of type long. Say I want to store a pair of things in sessions: a reference to an object of type User (which includes a reference to an object of type UserManager) and a timestamp to know when we received the last request from that session. Apart from that reference in the user, both classes consist of primitive attributes, IDs, names, strings with SQL, and the like. 1. Is the reference to the user storable? (My doubt here is what kind of things are not serializable indeed, I have a vague idea of this, I think I cannot store a reference to a db handler, or a file handle, but I cannot respond accurately to that question in general.) 2. Do I need to create more columns in the table or everything goes to the a_session column? 3. Could one set up things in a way that allows the database to see the timestamps and program a trigger to delete old sessions? Or is there a standard idiom for doing this in a different way? Thank you very much, -- fxn
Basic usage of Apache::Session::Oracle
If I understand it correctly, Apache::Session::Oracle uses a table called sessions with at least two columns, one called id, of type varchar2(32), and another called a_session, of type long. Say I want to store a pair of things in sessions: a reference to an object of type User (which includes a reference to an object of type UserManager) and a timestamp to know when we received the last request from that session. Apart from that reference in the user, both classes consist of primitive attributes, IDs, names, strings with SQL, and the like. 1. Is the reference to the user storable? (My doubt here is what kind of things are not serializable indeed, I have a vague idea of this, I think I cannot store a reference to a db handler, or a file handle, but I cannot respond accurately to that question in general.) 2. Do I need to create more columns in the table or everything goes to the a_session column? 3. Could one set up things in a way that allows the database to see the timestamps and program a trigger to delete old sessions? Or is there a standard idiom for doing this in a different way? Thank you very much, -- fxn
Basic usage of Apache::Session::Oracle
If I understand it correctly, Apache::Session::Oracle uses a table called sessions with at least two columns, one called id, of type varchar2(32), and another called a_session, of type long. Say I want to store a pair of things in sessions: a reference to an object of type User (which includes a reference to an object of type UserManager) and a timestamp to know when we received the last request from that session. Apart from that reference in the user, both classes consist of primitive attributes, IDs, names, strings with SQL, and the like. 1. Is the reference to the user storable? (My doubt here is what kind of things are not serializable indeed, I have a vague idea of this, I think I cannot store a reference to a db handler, or a file handle, but I cannot respond accurately to that question in general.) 2. Do I need to create more columns in the table or everything goes to the a_session column? 3. Could one set up things in a way that allows the database to see the timestamps and program a trigger to delete old sessions? Or is there a standard idiom for doing this in a different way? Thank you very much, -- fxn
Re: Basic usage of Apache::Session::Oracle
On Mon, 29 Apr 2002 01:11:59 +0200 F.Xavier Noria [EMAIL PROTECTED] wrote: : If I understand it correctly, Apache::Session::Oracle uses a table : called sessions with at least two columns, one called id, of type : varchar2(32), and another called a_session, of type long. I am sorry this question has arrived several times, I didn't receive it for hours and I thought something went wrong with previous attempts. -- fxn
Re: How to generate pre-filled forms? (fwd)
On 29 Apr 2002 09:16:42 +1000 simran [EMAIL PROTECTED] wrote: : Have a look at the HTML::FillInForm module as well... Yeah, thank you, I'll give it a try. I guess this is a natural candidate for an output chain, the HTML generated by two or three Apache modules will need that post-process, so I plan to use HTML::FillInForm with Apache::Filter, it will be the first application of my recent study of the Cookbook I couldn't have produced before I read it, magnific! -- fxn
How to generate pre-filled forms?
I am writing some modules that receive a form, process it, and return a page that includes that very form. Is there a standard way to fill that returned form so the user sees the same data he sent there, as CGI.pm does? -- fxn PS: I am using Apache modules + HTML::Template if that matters.
Re: How to generate pre-filled forms?
On Fri, 26 Apr 2002 16:15:52 +0200
F. Xavier Noria [EMAIL PROTECTED] wrote:
: I am writing some modules that receive a form, process it, and return a
: page that includes that very form. Is there a standard way to fill that
: returned form so the user sees the same data he sent there, as CGI.pm
: does?
: PS: I am using Apache modules + HTML::Template if that matters.
I summarize the approaches I've found:
* Generating everything in the module as usual, maybe storing
selects or things that complicated in template plain variables
instead of putting them in the very template.
* One can pass an object reference to a template as long as it has a
method called param that behaves as CGI::param(). The idea is that
TMPL_VAR color will be translated to $r-param('color').
* HTML::FillInForm parses an already constructed HTML page and
fills its forms out of the box invoking a param() method on a
passed reference, as above. I think is what I'll choose.
I'd need to know now wheter Apache::Request's param() is OK here.
Thank you!
-- fxn
[OT] Doubt on directories for development
I am working in my first mod_perl real-life project, I would like to ask you for a directory layout for development. The fact is that developers in my team have Apache under /usr/local in Linux machines, but we would prefer to develop as normal users, not as www or nobody, though that will be the user in production. What is the standard way to configure things for that? We have created somehow the Apache directory layout under the root of the project tree and call httpd -f project_root/conf/httpd.conf, where we customize the user and group (in my case fxn), full paths to log and pid files writable but that user, etc. but ServerRoot is /usr/local/apache and the original modules under /usr/local/apache are there, so we cannot use $r-server_root_relative to access, say, to application config files which seems to be standard (and quite natural) idiom. The httpd.conf in CVS is a template customized once per-machine with a script. I would appreciate any hint very much, we could begin right with a good layout next Monday. Thank you very much! -- fxn
[OT] Doubt on directories for development
I am working in my first mod_perl real-life project, I would like to ask you for a directory layout for development. The fact is that developers in my team have Apache under /usr/local in Linux machines, but we would prefer to develop as normal users, not as www or nobody, though that will be the user in production. What is the standard way to configure things for that? We have created somehow the Apache directory layout under the root of the project tree and call httpd -f project_root/conf/httpd.conf, where we customize the user and group (in my case fxn), full paths to log and pid files writable by that user, etc. but ServerRoot is /usr/local/apache and the original modules under /usr/local/apache are there, so we cannot use $r-server_root_relative to access, say, to application config files which seems to be standard (and quite natural) idiom. The httpd.conf in CVS is a template customized once per-machine with a script. I would appreciate any hint very much, we could begin right with a good layout next Monday. Thank you very much! -- fxn
doubt on how long the cookbook will apply
I have the Eagle book but have not buyed the Cookbook yet. I wonder whether the way Perl modules are written nowadays is going to be significantly altered by Apache 2.0. If it won't, I'll definitely buy it this weekend. -- fxn
how to identify an interrupted downloads?
I would like to know whether in the server side one can figure out if a user has completed the download of a known file. Would bytes_sent() give the actual number of bytes sent if the download gets interrumpted by the client? Would yo know a better approach if not? -- fxn
Re: how to pass data in internal redirects?
On Tue, 26 Feb 2002 08:32:37 -0500 Henigan, Timothy [EMAIL PROTECTED] wrote: : I don't know if this is the best design, but it works for this application. : If you made it this far into the email, you might be interested in some : sample code...let me know. If you have comments, please speak up. I'm the : only developer on the project, so if I've gone off the deep end, I might not : notice. Yeah, I am surely biased because in my company everything is done with Java where servlets act as controllers and forward requests to JSPs. Here people basicaly put data in the session object, for instance a User associated with the session. You have static data shared by everybody... it's a bit different as you probably know [*]. But I want to learn the multi-processes way of program with Apache and his related technologies. I believe, for instance, the Java people here at work do not completly realize they use the session object both to store state _and_ as a cache mechanism sometimes. You are not aware of what you are taking for granted until you play with other techniques. So, a controller could in principle perform a call to a template engine as yours does, conceptually there is no need to do that internal redirect. In fact, there is no need to have two different files if I take the pattern a bit further. For instance, I believe a page written in Embperl or PHP could begin with the controller code and once finished the view code could follow, that would be MVC too in my opinion. Well, just sharing thoughts. -- fxn [*] If needed, load balancing is done taking sessions into account.
how to pass data in internal redirects?
As an exercise studying mod_perl I am trying to see how could the MVC pattern be implemented. I've thought a possible approach would be to write the model using normal Perl classes, and controllers and views with Apache modules. I suppose that controllers would use internal redirects to call the views, is there a way to pass Perl data this way? For example, in the hangman game in O'Reilly's book a controller would load a session from the cookie, process user's guest, modify the state and redirect the request internally to the view. Ideally the view shouldn't read the data to display from the database again... could it be passed somehow by the first content handler? -- fxn
cleanest way to have globals in a CGI
Hello, I am the author of a CGI written in Perl (a single file) which is publicly available. Currently there are some file-scoped lexicals used in routines and I would like to change that in the next release in case anyone wanted to run it under Apache::Registry. Since there would be just one Perl interpreter I guess plain use vars would add symbols to a in principle shared by more code main namespace, do you know whether there is a standard, clean solution for this? -- fxn
Re: cleanest way to have globals in a CGI
On Mon, 18 Feb 2002 15:04:16 +0100 Me myself [EMAIL PROTECTED] wrote: : Since there would be just one Perl interpreter I guess plain use vars : would add symbols to a in principle shared by more code main namespace, : do you know whether there is a standard, clean solution for this? I somehow was thinking packages are mainly used for writing modules or classes and that wouldn't be idiomatic to start a CGI with a package declaration. Silly me, packages introduce namespaces and that is precisely what was needed. Nevertheless, it turns out that Apache::Registry takes care of that problem wrapping CGIs in corresponding different packages he declares, so a valid answer to my question appears to be that a standard, clean solution is to do nothing special to protect globals. -- fxn
