Re: perl.apache.org problem
Quoting Stas Bekman [EMAIL PROTECTED]: Cees Hek wrote: It looks like something has gone awry with the perl.apache.org website. It is currently pointing to the Apache Portable Runtime website. You can bypass it by going directly to: http://perl.apache.org/index2.html This looks like the result of a change to put up a protest page at the start of every *.apache.org website. Perhaps someone can notify the powers that be to fix the problem. There is no problem, Cees. This is done by the Apache Software Foundation. mod_perl is an ASF project if you didn't know. Have you read what it says on http://perl.apache.org/? Hi Stas, The protest page wasn't the problem. I did noticed that they had put it on all the .apache.org websites. However when I went to perl.apache.org, instead of seeing the protest page or the mod_perl website, I got the Apache Portable Runtime website (ie the page found at http://apr.apache.org). I guess the admins at the Apache Foundation noticed quickly enough and fixed the problem. Cheers, Cees -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Quoting Michael [EMAIL PROTECTED]: On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said... The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). Cheers, Cees -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
perl.apache.org problem
It looks like something has gone awry with the perl.apache.org website. It is currently pointing to the Apache Portable Runtime website. You can bypass it by going directly to: http://perl.apache.org/index2.html This looks like the result of a change to put up a protest page at the start of every *.apache.org website. Perhaps someone can notify the powers that be to fix the problem. Cheers, Cees Hek -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mp2: architectural question re authentication handlers
Quoting Carl Brewer [EMAIL PROTECTED]: Forgive me for asking yet another fundamentally basic question. I'm cutting a web app over from PHP to mod_perl 2, and am wondering how 'best' (for which there are many flavours ...) to handle authentication. At present I've knocked up a site that does auth via a form and state tracking with Session.pm. The form checks usernames passwords against a MySQL database, and the state is maintained by Session. This seems quite logical to me, coming from essentially a CGI background, but the discussion of handlers around here makes me believe there's a better way? I would highly recommend the Eagle book if you are looking to move beyond CGI when using mod_perl. I know that you are looking at mod_perl2, and the Eagle book does not cover mod_perl2, but it will give you great insight into how mod_perl and Apache works. And lucky for you, since you are interested in Authentication and Authorization, that chapter happens to be available online. http://modperl.com:9000/book/chapters/ch6.html Also checkout the great documentation available at http://perl.apache.org/ If you want a good example of how to implement Authentication and Authorization in mod_perl, then look on CPAN for the man Apache::Auth* modules. I have used Apache::AuthCookie in many projects and it has relatively good documentation. You will also find tonnes of info on Authentication if you search the mailing list archives. I see threads here discussing the use of handlers, which I don't really understand how they fit into the picture, they seem to my poor understanding to be a hardcoded chunk in httpd.conf, for handling authentation/state. Is there anywhere a dumb beginers guide to how this works? The easiest way to explain it is to just look at Apache's Basic Authentication support at first. The one where the browser pops up a window and you type in your username and password, and Apache authenticates the user for you before it will allow the CGI script to be executed or the html file to be downloaded. You configure that in httpd.conf or in .htaccess files, telling Apache who has access to specific files and directories. This is just your standard access control stuff. Now imagine that you can use that same core functionality in Apache, but write the routines yourself in perl. And instead of the ugly login popup you can instead create an HTML login page. Do they set environment variables or something that a script can then look for that the script can be sure is legit? Yes, they set the HTTP_USER variable to the users login when a user is authenticated. But your script doesn't need to even worry about that, because Apache won't execute the script unless the user is authorized. So if the script is executing, then the user is authenticated... for now I'm continuing with my form based authentication, but is there a 'better' way? And if so, what makes it better? The biggest benefit I find is that you can separate your authentication code from the rest of the code. With an Authentication handler, your CGI script or content handler will never even be executed unless the user has been authenticated. Also, how would you use a CGI based authentication scheme to limit access to a static HTML file, or an image? It can't be done cleanly. But with Authentication handlers, you can hook them to a Location or Directory directive or even a Files directive in the httpd.conf file. So you can protect an entire directory with ease. Cheers, Cees
Re: mod_perl slower than expected?
Quoting Trevor Phillips [EMAIL PROTECTED]:
However, when I used the revised modules with the Apache Module, I'm only
getting a marginal performance increase!
Since the bulk of the work is being done by modules common to the Apache and
FastCGI front-ends, I am at a loss as to explain why there is such a vast
difference in performance.
Is there anything I may be missing about the general configuration or
environment of mod_perl which may be causing this strange situation?
You would have to provide your configuration for anyone to be sure, but there
are a couple of things to check for:
- Are you only checking the first time you load the page? mod_perl still needs
to load all the perl modules on the first request to a page, unless you have
specifically pre-loaded them in the apache configuration. Subsequent page loads
should be faster.
- Are you sure you are running the script under mod_perl? try checking for
$ENV{MOD_PERL} in the script you are executing. If it is not defined, then you
are not running the script under mod_perl.
- Could it be that you have a small number of child processes running, or are in
single-process mode, and your HTML page has several images on it? This could
affect the speed at which the page displays (although you should see it with
FastCGI as well). Your safest bet is to use something like wget or the LWP
scripts to get the page, and then you can easily time it.
- are you using mod_perl2? I don't know enough about mod_perl2 to help here,
but possibly you are having thread issues with the threaded MPM.
mod_perl should be just as fast as FastCGI as they achieve similar goals by
eliminating the perl startup and compile stages. If this doesn't help you, then
please provide more info on your setup.
Cheers,
Cees
Re: mod_perl caching form data?
Quoting David Ressman [EMAIL PROTECTED]: something's caching previously entered form data and displaying it back to me as the default values in those same forms. As an example, this form has a text field that asks for IP addresses, and the text input will occasionally be filled out with the IP address of a system that you had entered a few minutes ago. If you do a view source in the browser, and check the form fields, do they have the VALUE=... paramters set? ie do you see something like this: input type=text name=ipaddress value=192.168.1.1 If that value=192.168.1.1 is set in any of your form fields, then your script is the cuprit. If your form fields don't have the value=192.168.1.1 set, or it is set to value=, then your browser is the culprit. Most modern browsers will offer to remember values you have entered into a form. On subsequent visits to the same URL, the values will be prefilled by the browser for you. mod_perl itself will never prefill form values for you. It is completely up to your script (or the modules it uses) to munge the data coming through. It is possible that you are creating your form fields with CGI.pm, which will use the currently POSTed parameters to prefill the form, or if you are using a module like HTML::FillInForm, which will also prefill form fields. But you would have to explicitly use these features in your script. HTH Cees,
Re: mod_perl caching form data?
Quoting David Ressman [EMAIL PROTECTED]: It is possible that you are creating your form fields with CGI.pm, which will use the currently POSTed parameters to prefill the form, or This sounds like the most likely culprit, even though I haven't explicitly turned anything on. It's possible that I've done it inadvertently. I'll check it out. Read the CGI.pm docs and you will find the cause of your problem: http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm#CREATING_FILL_OUT_FORMS_ Cheers, Cees
Re: [error] Insecure dependency in unlink while running with -T switch at /usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106
Quoting Martin Moss [EMAIL PROTECTED]:
All,
Can Anybody see what I'm doing wrong here?
I have the following error :-
[error] Insecure dependency in unlink while running with -T switch at
/usr/lib/perl5/site_perl/5.6.0/Apache/Session/Store/File.pm line 106.
The problem is not with your code, it is that Apache::Session::File does
not work in Taint mode. Apache::Session::Store::File gets the session ID from a
file (which means session_is is tainted), and then uses the tainted session_id
to delete a file (hence the unlink error).
A quick fix for this is for you to untaint the session ID yourself after
the session has been unserialized. Put the following two lines right after you
tie the session:
$session{_session_id} =~ /^([a-zA-Z0-9]+)$/;
$session{_session_id} = $1;
This probably should be fixed in Apache::Session itself as I am sure other
people will run into it.
By the way, you really shouldn't be using Apache::Session::File anyway for
performance reasons. At least use Apache::Session::DB_File which most likely
doesn't suffer from this taint problem and will be much quicker.
Cees
When I run the following subroutine:-
sub delete_session
{
my $self=shift;
my $session_id=shift;
if ($session_id =~ /^(\w\w*)$/)
{
$session_id = $1; # $data now untainted
}
else
{
die Bad Tainted data in $session_id;# log this somewhere
}
die $self-{lh}-maketext(No Session_id given) unless ($session_id);
my $t=time;
my %session;
my $Directory = My::Conf::APACHE_SESSIONS_TMPDIR;
my $LockDirectory = My::Conf::APACHE_SESSIONS_LOCKDIR;
$Directory=XX_GR_XX$Directory.XX_GR_XX; #e.g.
'/path/to/dir/'
$LockDirectory=XX_GR_XX$LockDirectory.XX_GR_XX; #e.g.
'/path/to/dir/'
if ($Directory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$Directory = $1; # $data now untainted
}
else
{
die Bad Tainted data in $Directory;# log this somewhere
}
if ($LockDirectory =~ /^XX_GR_XX(.*)XX_GR_XX$/)
{
$LockDirectory = $1; # $data now untainted
}
else
{
die Bad Tainted data in $LockDirectory;# log this somewhere
}
#Load an existing session
eval
{
tie %session, 'Apache::Session::File',$session_id,
{
Directory = Bficient::Conf::APACHE_SESSIONS_TMPDIR,
LockDirectory = Bficient::Conf::APACHE_SESSIONS_LOCKDIR,
};
};
if ($@)
{
die $self-{lh}-maketext(Couldn't Load Apache::Session - \[_1]\
For '\[_2]\',$@,$self-UserName);
}
print STDERR Just about to unlink\n;
tied(%session)-delete;
return 1;
}
Re: Apache::UploadMeter configuration problem
Quoting Konstantin Yotov [EMAIL PROTECTED]: Hello! :) I install Apache::UploadMeter, but when I when I add this in startup.pl use Apache::UploadMeter; $Apache::UploadMeter::UploadForm='/form.html'; $Apache::UploadMeter::UploadScript='/perl/upload'; $Apache::UploadMeter::UploadMeter='/perl/meter'; Apache::UploadMeter::configure; following instruction from this modul help, Apache starts with error Use of uninitialized value in numeric gt () at /usr/lib/perl5/site_perl/5.6.1/Apache/UploadMem line 300. /usr/sbin/apachectl: line 211: 5235 Segmentation fault $HTTPD -t You are getting a segfault, and need to provide a backtrace if anyone is going to be able help you. If you read the SUPPORT document that comes with mod_perl, it will explain what information you should include, including instructions on how to get a backtrace. Also note that Apache::UploadMeter requires StackedHandlers support to be built into mod_perl (you should be able to look in Apache::MyConfig to see if you have StackedHandlers support). I suspect that your problem doesn't have anything to do with Apache::UploadMeter directly though. The message Apache provides about Apache::UploadMeter is just a warning, not a fatal error. Cees
Re: mysql password encryption
Quoting Martin Moss [EMAIL PROTECTED]: All, I wish to let a user use the same password for them to authenticate to a multitude of mysql Databases AND to authenticate themselves on my modperl site. the problem I have is that I store the password in the database as a Password field. However when I wish to use DBI to connect to another mysql database I cannot use the Password stored in the database as it comes out encrypted. I really don't want to store the unencrypted password anywhere on the system. Is there a way to let DBI/mysql know that the password I am giving them is ALREADY encrypted? A feature like that would defeat the purpose of encrypting the password in the first place. The point of encrypting the password is so that if someone gets their hands on the password list, they can not use the encrypted password to access the system. They would have to crack the passwords first before using them to access the system. By allowing someone to access the system with an already encrypted password, then your passwords might as well not be encrypted at all. Since you are using MySQL, have you looked at using the mysql_read_default_file option to store your password in a config file? Using a DSN like the following allows you to keep the username and password in a config file. Check the DBD::mysql perldocs for more info, and the MySQL docs for all the parameters you can put in such a file. DBI:mysql:test;mysql_read_default_file=/etc/mysql/test.my.conf and in /etc/mysql/test.my.conf [client] user = www password = thebigsecretpassword Then protect the file: chown www /etc/mysql/test.my.conf chmod 400 /etc/mysql/test.my.conf You still have the password in plain text, but it is readable only by root and the user that runs the webserver. You can use this to connect to multiple MySQL servers as long as the access tokens are the same on all servers. Cees
Re: mod_perl mod_php
Quoting Jesse Erlbaum [EMAIL PROTECTED]: I have a general question for the list: Do people often use BOTH of these environments at the same time? It seems to me that there would be little benefit to using both. Am I mistaken? We have some old apps that are written in PHP, but are predominantly a perl shop. To keep the apache processes from getting too big, we just run 3 apache servers currently bound to different IPs, but probably moving to a rev-proxy system when it is needed. Cees
Re: PerlChildInitHandler doesn't work inside VirtualHost?
Quoting Jason W May [EMAIL PROTECTED]: Running mod_perl 1.26 on Apache 1.3.24. I've found that if I place my PerlChildInitHandler inside a VirtualHost block, it is never called. It doesn't really make sense to put a PerlChildInitHandler inside a VirtualHost directive. It is only called when the Apache Child process is created, not when a new request comes in. If you explain what you are trying to accomplish, maybe we can recommend a better Handler to tie into. Cees
Re: when to mod_perl?
Quoting md [EMAIL PROTECTED]: Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? You can easily build an application that uses the best of both worlds. The biggest benefit of mod_perl is speed, but you don't have to tie yourself tightly to mod_perl to get that benefit. I would build your application using plain old CGI, following the guidlines that mod_perl provides for running CGI applications under the Apache::Registry module. If you properly analyse your application, and build small tight CGI scripts, then when the load goes up, you can pick and choose the heaviest hit scripts and run them under Apache::Registry for the performance boost. Also, if the load goes really high, you can ask for more hardware, and run the entire site under Apache::Registry without any code changes. I would recommend taking a look at CGI::Application. It provides a very clean framework for building CGI programs, and by using it, you will avoid most if not all of the pitfalls that most CGI programs have that require them to be recoded, or cleaned up for use with Apache::Registry. Good luck... Cees
Re: DBI error_log Logging
Quoting Jayce^ [EMAIL PROTECTED]:
I've been researching the different modules for pushing your access log to a
dbi storage vs. local file and have one question which I'm not sure any of
them are able to do yet. Perhaps somebody has already thought of this and
I'm just not seeing the answer (very likely).
I need to log my error_log entries also, not just the access log.
For a non mod_perl way of dumping error_log into a DB just use the standard
Apache ErrorLog directive with a pipe:
ErrorLog | /usr/local/apache/bin/error_logger.pl
and in error_logger.pl just read from STDIN ( while () {#do something} ) and
do what you please with the log entries.
Cees
If there is one, especially if it's Apache::DBILogConfig (my favorite
appearing so far) with that same customization, that would be excellent.
Otherwise I'd like to know, because I'll probably have to make one *real*
quick :) Also, if it has the ability to either trigger an event, or just
log to file the inability to log via DBI, that would be nice.
Jayce^
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE89q8CoTgdT9hhlCIRAjoEAJwKsO9LYavsWMQGwUsD11E1Gr9HiACgl1yR
mvvJRsub4he4A4PaPoA8PEI=
=E5ID
-END PGP SIGNATURE-
--
Cees Hek
SiteSuite Corporation
Re: Apache::DBI or What ?
On Fri, 2002-03-22 at 11:42, Andrew Ho wrote: Hello, EFI will have many different users, users as in database users. So am I EFjust screwed and won't be able to keep connections open? Do you mean users as in actual RDBMS level users? In other words, when you say database users you mean different username/passwords used from, say, a command-line SQL client? If your answer is yes then indeed, this is exactly the situation the Guide is talking about--you're screwed and probably shouldn't keep connections open. You'll have to incur a connect on each HTTP request. What would be ideal is if the database would allow you to change the user on the current connection. I know PostgreSQL will allow this using the command line interface psql tool (just do \connect database user), but I'm not sure if you can do this using DBI. If this was possible, then you could always connect to DBI using the same username/password so Apache::DBI gives you a cached connection, and then once you have the connection, you can change to the user you want. Does anyone know if any datbases support this sort of thing? Cees EFI am using Postgress, I am wondering how big DBs deal with this sort of EFthing. I am also wondering what the actual overhead is in starting the EFconnection and if there is anything that I could to to limit that EFwithout validating a specific user. In large DB projects where you expect high levels of concurrency I haven't heard of anybody using RDBMS-level users for authentication purposes. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Cookies and IE in mod_perl
Some browsers don't accept cookies sent allong with a redirect header.
A simple workaround is to leave your cookie in the header, but move the
redirect to a META HTTP-EQUIV tag in a blank HTML document.
I'm not sure if IE 6.0 suffers from this but I suspect that this is your
problem. So this isn't really a mod_perl problem, but likely a browser
problem.
Also, if you want to see exactly what headers your apache server is
sending out, or headers your client is sending in, have a look at
Apache::DumpHeaders. It saves putting those warn statements in your
code.
Cees
On Sun, 2002-03-24 at 14:44, Jesse and Rebecca Stay wrote:
Ok - I got rid of the Apache::Cookie stuff, and am now doing things manually,
but it still doesn't generate a cookie in IE. It still works in Netscape. I
get a redirect, but no cookie. Here is my code:
my $r = Apache-request;
$r-content_type('text/html');
$r-err_headers_out-add('Set-Cookie' = 'userSession=test;
domain=.hainesfamily.org; path=/; expires=Mon, 25-Mar-2002 03:30:43 GMT');
$r-headers_out-add(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
my $headers_out = $r-headers_out;
foreach (keys %$headers_out) {
warn $_=$headers_out-{$_};
}
return OK;
The warn produces the following:
Set-Cookie=userSession=test; domain=.domain.org; path=/; expires=Mon,
25-Mar-2002 03:30:43 GMT at /path/to/script.pm line 326.
Location=/r/common/loginWelcome at /path/to/script.pm line 326.
Connection=close at /path/to/script.pm line 326.
Transfer-Encoding=chunked at /path/to/script.pm line 326.
Content-Type=text/html at /path/to/script.pm line 326.
Am I doing something wrong???
-Jesse Stay
On Saturday 23 March 2002 06:43 pm, Eric Frazier wrote:
Strong suggestion. Look at an existing cookie that works in IE whatever,
copy it, then look at the header that Apache::Cookie is making.
This oop cookie crap really bugs me since a cookie is just a stupid header
line, not that big of a deal to parse, or write by hand.
Abscraction is for things that make good objects and that are HARD, cookies
in my opinon don't fit into that category.
I strongly bet it has to do with the expire date, also look at the docs,
and the code itself under the expires sub. I haven't done e com crap for a
while now, but I had lots of trouble getting IE to get it right. Remember
Netscape invented the cookie, then IE had to go and tweak with it.
Eric
At 09:21 PM 3/23/02 -0500, Jesse and Rebecca Stay wrote:
I guess in particular, does anyone know of any known issues with
Apache::Cookie and IE6.0 (or any other versions)?
On Saturday 23 March 2002 07:09 pm, Jesse and Rebecca Stay wrote:
Here is the code I use (in this particular case it is being used with a
redirect, but it doesn't work in any case.):
my $cookieContent = Apache::Cookie-new(
$r,
-name= 'userSession',
-value = $cookieValue,
-expires = '+365d');
$cookieContent-bake();
$r-headers_out-set(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
I tried expires = '+1Y', but that didn't work either. Adding the
domain doesn't do anything either.
On Saturday 23 March 2002 06:44 pm, Frank Wiles wrote:
On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay
[EMAIL PROTECTED] wrote:
Has anyone had any issues in getting cookies to work with IE using
mod_perl? I have tried using both CGI::Cookie and Apache::Cookie,
and in both instances it works just fine under Netscape, but on IE
it doesn't even try to set the cookie. Any ideas?
What are you expire times on your cookies? We ran into a situation
where I work that all of the Windows machines were in the wrong time
zone and with a 2 hour expire, IE would not set the cookie because it
thought it was already expired. Netscape would however set the cookie
anyway.
This may not be your problem, but it may be something to think
about.
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Re: file globbing question
On Wed, 2002-02-20 at 13:27, John Stauffacher wrote: All, I am a bit confused as to what httpd.conf directives need to be used in order to get apache to execute a PerlHandler when it encounters a certain file type. What I want to do: Execute a handler whenever a *.qw file is accessed. The same handler whether or not the file exists and not look for the file. So the user makes the request: get /somewhere/my.qw and gets the response moo. Then they request /other/place/boo.qw and gets the response moo. I have tried using a Files directive, but it envokes the handler, then looks for the file and throws a 404. Any ideas? The Files directive is the right way to go. Are you sure you are returning OK in your Handler? If you return something else (like DECLINED) then Apache will take over the request and handle it in the default manner (ie look up the file). Returning OK lets Apache know that the request was dealt with appropriately and it can move on to the next phase. Cees
Re: Is 'PerlHandler Apache::Registry MySimplePerlModule' possible?
On Thu, 2002-02-07 at 05:31, Zsolt Czinkos wrote: Hello Is it possible to insert my Set-Cookie headers after a modperl script? for exapmle: httpd.conf ... PerlFreshRestart On PerlModule SetMyCookies PerlFixupHandler SetMyCookies PerlSetVar SessionDataPath /tmp/apache_session PerlSetVar SessionLockPath /tmp/apache_session_lock Alias /modperl /home/czinkos/IMI/apache/modperl Location /modperl PerlModule Apache::Registry SetHandler perl-script PerlHandler Apache::Registry SetMyCookies Options ExecCGI /Location ... /httpd.conf The script is simple. It adds to cookies to the header. e.g. $cookie-bake; I've tried it, but id didn't work. I'd like to add some extra header after everything is done. You should look at the Apache::Filter module which will allow you to do this. Cees
Re: Silly Newbie Question: cookies and such
On Tue, 13 Nov 2001 04:28, you wrote:
I need to make an Apache module (not a Registry script) which will:
1. Check for a cookie, and if not there, pushhandler to a module for
logging in (keeping the original request at hand for use after they
succeed in logging in).
2. Extract data from the cookie (encrypted for security?)
3. Based on data from both the query string ($r-args?) and from data in
the cookie, pushhandler to another module.
I have looked at Apache::AuthCookie - it didn't seem to make much sense
to me. Apache::Session looks promising, but the instructions don't say
how to set up the mysql tables, etc. My worst problem is that I haven't
had occasion to deal with cookies much (setting, checking,etc.) in the
past and I know this is hampering my understanding.
You should definately be using Auth::Cookie for this. I would give the docs
another read. It took me a couple of tries to get it working successfully,
but I have implemented it in about 4 or 5 applications, and it works
flawlessly.
With Auth::Cookie it will handle the cookies for you, it will do the
redirection to your login page for you, and it can handle logouts as well (by
expiring the cookie).
As for Apache::Session, it is really just a keyed data store with expiry
times. You give it some data, and it gives you a key. If you come back
later and give it the same key, it gives you back your data.
A lot of people use Auth::Cookie and Apache::Session together to build a
session management system, but I prefer just using a ticket based system with
Auth::Cookie alone (See the Eagle book on how to do ticket based
authentication). I have included a sample Auth::Cookie implementation that
might give you some ideas. It is not complete, but it might get you going (I
have stripped out some of the irrelevant code, so it probably won't work out
of the box). Also you will have to provide your own login.pl and logout.pl
scripts (I would use the examples that come with Auth::Cookie until you get a
working system, then you can look at building your own.
In conclusion: I'm making a system/site where no .html files even exist.
I need to handle security via a mysql db, and to push handlers based on
a part of the url and a piece of the cookie which identifies the user as
either a teacher, student, or parent (oops... I gave it away ;-)
After Auth::Cookie has finished it's phase, it will set the REMOTE_USER
environment variable to the user that logged in. You could just as easily
set this to 'teacher' or whatever. Then your content handler can look at
this variable and decide what to do.
HTH
Cees
package My::Auth::AuthCookie;
require 5.000;
use strict;
use Apache::AuthCookie;
use My::Crypt;
@My::Auth::AuthCookie::ISA = qw(Apache::AuthCookie);
#
##
# There are far more secure ways of handling the passphrase then keeping it in
# the actual code, but this is by far the easiest...
sub SECRET () { 'No one will ever guess this passphrase :)'; }
my $CRYPTER ||= new My::Crypt; # This utility just uses the Crypt::CBC and
# Storable modules to encrypt and decrypt perl
# data structures. It also does an MD5 checksum
sub authen_cred ($$\@) {
my $self = shift;
my $r = shift;
my @creds = @_;
#
# get the entered details
#
my $email= $creds[0];
my $password = $creds[1];
#
# ensure that the user is valid and authorized...
# right now it accepts any email and password combo,
# so obviously you would check this in a database or
# something
#
if ($email $password) {
return $self-makeTicket($r, $email);
}
else {
return;
}
}
sub authen_ses_key ($$$) {
my $self = shift;
my $r = shift;
my $ticket = shift;
#
# verify the ticket (to make sure no-one has tampered with it and it hasn't
expired etc...)
#
my ($result, $message) = $self-verifyTicket($r, $ticket);
#
# Check the result and act appropriately...
#
if (!$result) {
# $r-log-error(Browser returned bad cookie ($message));
return undef;
}
else {
#
# Make and set a new cookie (so that the 'time' in the cookie is
updated
and expires
# works as expected - since last access etc...)
#
my $new_ticket = $self-makeTicket($r, $message);
$self-send_cookie($new_ticket);
#
# Return the 'message/string' which will be set in the environment
# under REMOTE_USER (aka.. $ENV{REMOTE_USER}). In our case that is
# the users email
Re: CGI.pm problem
On Wed, 31 Oct 2001 02:31, you wrote: Hello, When I try to make a CGI object in my Apache/mod_perl handler a la $q = CGI-new(); The server just don't reply. Actually it works just fine until I try to submit a form, then it just hangs and Apache doesn't send anything back. If I remove this object creation line, then I can submit my form (but then its no use, i can't use the data). What could be the problem? What version of CGI.pm are you using? I seem to remember a problem with mod_perl and an older version of CGI.pm where CGI.pm was fooled into thinking it was run in command line mode. If you are seeing the following line in your logs then this is definately the cause of your problem: (offline mode: enter name=value pairs on standard input) To fix this put $CGI::NO_DEBUG=1 near the top of your program or upgrade CGI.pm. Cees ps you should be using Apache::(Request|Cookie) to get your GET/POST/COOKIE parameters, as it is more efficient. ---
Re: ANNOUNCE: Apache::OpenIndex
On Fri, 28 Sep 2001 07:36, George Sanderson wrote: Apache::OpenIndex (OpenIndex-1.00.tar.gz) was uploaded to CPAN on 14Sep2001 and is currently released. This was my first module. I enjoyed journey. Looks really good. I think the mod_perl community can use a lot more applications like this (something that is useful right out of the box). I guess instead of complaining I should start coding... One issue I noticed. I have a phobia of frames, and it looks like Mozilla and konqueror do as well. Your code keeps reloading itself into a new frameset under certain actions. I would recommend that you get rid of frames all together, but that might just be my phobia speaking... Cees OpenIndex provides a file manager for an Apache modperl web site using a web browser. It is a extensive rewrite of the Apache::AutoIndex module (written by Philippe M. Chiasson), which in turn was a remake of the autoindex Apache module. OpenIndex also provides the same functionality as autoindex, therefore it can be used to both manage and navigate a web site. A demo is available at: http://www.xorgate.com/Apache/OpenIndex/demo ++ | George Sanderson [EMAIL PROTECTED] | http://www.xorgate.com ++
Re: Another way to perhaps do this......
On Fri, 28 Sep 2001 16:40, Steven Boger wrote: I've been netsearching for hours. It's time to beg for help... My apache has a hacked mod_include that has a new directive, OAS: !--OAS SETUP=www.realmedia.com/Samples/lx.shtml@TopLeft,TopRight,BottomLeft, BottomRight-- !--OAS AD=BottomRight-- Can I somehow run those directives right from mod_perl If you have the Eagle book (if you don't you should get it), it talks about an Apache::SSI module on pg 94, and then shows you how to implement it. You will find a nicely packaged up Apache::SSI on CPAN by Ken Williams. I haven't used it myself, but it should do what you are looking for. You will have to hack this code to handle your OAS calls though... Cees
Re: Converting Perl section variables into plain text directives
On Fri, 24 Aug 2001, Eric Hammond wrote: Is there any way to take the Apache::ReadConfig name space (variables set in Perl sections) and generate plain text Apache directives? I don't know if there is a simple answer to this one, but the way I would handle it is to scrap the Perl sections, and generate the entire config file using a standalone perl script. Then just change your apache start script to first generate the config file, and then start Apache. This way you get the best of both worlds! Your config file is dynamically generated, and you can create a light apache without mod_perl. Since you already have a half perl, half text config file, It would probably be quite easy to use one of the many Template modules out there to simplify this process... I guess a module that does this automatically would be interesting, but it would really only be useful to recover from some bad planning :) (and I guess we've all been there at one point or another) Cees For example, assuming some_function() returns myhost, I would like to convert the variables generated by: Perl $ServerName = some_function(); $Port = 80; /Perl into: ServerName myhost Port 80 I have a hypothetical situation where a friend of a friend spent a lot of time setting up a nice Perl configuration for an extended family of web servers with various requirements. He then realized that one of the requirements was that some of the web servers run without mod_perl (to serve static files and proxy requests to separate mod_perl servers). My hypothetical friend of a friend is very embarrassed. After studying the instructions given in the Eagle book on how to convert plain directives into Perl variables, it seems that it should be possible to traverse the name space in Apache::ReadConfig and unwind the directives into something that standard mod_perl-less Apache could process. In fact, I have embarked on a project to build just such a tool. Before I go too far, though, I thought it would be helpful to seek wisdom here. Perhaps somebody else has already done this? Perhaps mod_perl already has the code embedded in it that could be used? Perhaps some wish to tell me it is near impossible in the general case and I should abandon my foolish quest? Of course, I realize that the output generated will not be able to duplicate any side-effects or dynamic nature of code in the Perl sections. One of the requirements for using this utility will be that you only need the end results stored in Apache::ReadConfig. I would be interested in suggestions for package naming if I do succeed to an extent that others might be interested in using it. Should I create a new method in the Apache::PerlSections name space or would this be stepping on Doug's toes? Please do let me know if anybody else has a use for such a tool. This will help me figure out how much time I should spend trying to handle the general cases instead of just writing it to meet my... er, my friend's... specific needs. Thanks -- Eric Hammond [EMAIL PROTECTED] -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
Re: Using CGI.pm in handlers
On Sat, 18 Aug 2001, Joachim Zobel wrote: I have a handler that needs to use CGI.pm to set a cookie. It seems to work correctly, but it fills my error log with (offline mode: enter name=value pairs on standard input) messages. I am doing If you are only using CGI.pm to set a cookie, you should really be using Apache::Cookie instead. It is much smaller and faster. But if you still want to use CGI.pm, you can load CGI.pm with debugging turned off. This should stop it from entering 'offline' mode. use CGI qw/-no_debug/; Cees
Re: module to hit back at default.ida atack ?
On Mon, 6 Aug 2001, Mark Maunder wrote: I have a test system up and running. Anyone want to write a mod_perl handler to redirect to a warning page if the clients IP is in the list? I'm not really sure which phase would be the least intrusive into existing applications. telnet www.swiftcamel.com Then hit enter and you'll see the latest list of servers that have attempted the hack including the number of attempts per IP address (comma seperated). So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... Cees
Re: CGI::Cookie vs Apache::Cookie -- help?
On Sun, 17 Jun 2001, will trillich wrote:
$r-log_error( qq(...id=$ID, sending cookie) );
my $cookie =
Apache::Cookie-new( $r,
-name = $cookie_name,
-value = $ID ,
-domain = $r-hostname,
-path = '/' ,
);
$r-header_out('Set-Cookie', = $cookie);
You forgot to bake your cookie... Read the Apache::Cookie docs again.
Get rid of the $r-header_out(...) line and use the following instead.
$cookie-bake();
Cees
Re: Is this feasible in Perl??
On Tue, 12 Jun 2001, F.H wrote:
Hi All,
I have a text file like this:
Name ,123-43-4352, JX, 1234
Sports,123-43-4352, SKI, BaseBall, swimming
Hobbies, 123-43-4352, H1,H2, H3
Hobbies, 123-43-4352, HH, HHH, 2
Hobbies,123-43-4352, H1,H43
Name ,223-63-9352, JX, 1234
Sports,223-63-9352, SKI, BaseBall, swimming
Hobbies, 223-63-9352, H1,H2, H3
Hobbies, 223-63-9352, HH, HHH, 2
Here is my issue, I am trying to access each record in this file by SSN
ie: (223-63-9352)
I want to be able to say:
for SSN = 223-63-9352, for Hobbies4 4th entry is HGFR.
You will want to learn how to use hashes instead of just using
arrays. Give the following (untested code) a try:
# Gather the data
my $data = {};
while ($line = INPUT) {
chomp $line;
my ($key, $ssn, @values) = split /\s*,\s*/, $line;
print STDERR Unparsable record: $line\n
unless $key =~ /^(name|sports|hobbies)$/i;
$data-{$ssn}-{lc $key} = @values;
}
# print the data
foreach my $ssn (keys %$data) {
print SSN: $ssn\n;
print Name: , join ', ', @{$data-{ssn}-{name}}, \n;
print Hobbies: , join ', ', @{$data-{ssn}-{hobbies}}, \n;
print Sports: , join ', ', @{$data-{ssn}-{sports}}, \n;
print \n;
}
Like I said, this is untested code , but it should give you an idea of
what you can do.
Cees
while ($line = INPUT){
@line = parse_line(',',0,$line);
if ($line[0] =~ /^NAME/gi){
$ssn = $line[1] ;
push(@ssns, $ssn);
}
if ($line[0] =~ /^Sports/gi ){
push(@sports, $line)
}
if ($line[0] =~ /^Hobbies/gi){
push(@hobbies, $line)
}
for ($i = 0; $i= $#ssns; $i ++)
{
print For $ssns[$i]\n;
for ($i = 0; $i = $#Hobbies ; $i++){
if ($Hobbies[$i] =~ $ssns[$i])
{ print Hobbies are: $Hobbies[$i]\n;}
}
I wanted to print out for each SSN corresponding SSN numbers but it's just
not working!!! If this is feasible in Perl I'd appreciate if someone could help.
Thanks
I.S
__
Get your own FREE, personal Netscape Webmail account today at
http://webmail.netscape.com/
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Real Widgets and Template Languages
On 29 May 2001 [EMAIL PROTECTED] wrote:
On Tue, 29 May 2001, Stephen Adkins wrote:
Right. I have many more requirements I eventually want to support
(such as internationalization). The trick is making the design such
that it works in the simple case for simple things, while supporting
advanced features for those who wish to use them. I think it is coming
together pretty well.
I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right
off the top. If my widgets aren't multilingual then I'll have to go
elsewhere. 75% of my apps are bi and trilingual.
I agree. I18L and L10N are very important these days.
I think we should bite the bullet and start talkin Unicode and ISO-639
language codes right at the beginning.
If a widget has a textual element to be used in rendering (ie/ label)
it should have as many language forms as the developer requires. If a
language form is missing it should kick down to a default language
(EN-CA for example - otherwise words like colour and flavour will be
mispelled ;-) ).
But it's not just textual elements that need to be multilingual. Where is
really gets hairy is with something like a price widget (what monetary
symbol is used, what decimal point, etc...). This isn't usually that hard
to do on one system (if it has good Locale support), but making it cross
platform and dependable will be more difficult. I have used the
Locale::Maketext module with some success in the past. It doesn't depend
on any system Locality libraries, you are required to build them yourself
for your specific needs.
Another thing to consider is how to handle language issues with
dynamically changing widgets. For example if a widget uses a select box
it could be filled in by one of three ways: hard-coded, config, or at run
time (through DB calls or something). If your application is
multi-language, then you need to provide multiple datasets to the widget
if it is a dynamically changing widget. This would probably be most
convenient by using closures:
my $dbh = database handle
$wc = Widget-controller();
$wc-language('fr_CA','fr','en'); # Tell the controller what language(s)
# you would like in order of precidence
my $get_categories = {
my $lang = shift; # will be one of (en, fr, fr_CA)
return $dbh-selectrow_array(q{
SELECT category
FROM categories
WHERE language = ?
ORDER BY category
}, $lang);
}
my $categories = $wc-widget(dynamic_select,
{ label = 'Category', dataset = $get_categories });
I don't think the widget should automatically check the users environment
(Language headers in the case of http), to decide what language to display
itself in. The reason for this is that I might only translate my website
into english and french, but the user has dutch as their preferred
language. The site should not display some parts in english/french and
it's widgets in dutch...
So by telling the controller what languages are acceptable, you can
restrict what it can do. Or perhaps the language should be decided by the
programmer at display time??
ie print $categories-display({language = 'fr_CA'});
That would get awful repetative if your displaying 20 widgets. But it
might be nice if you want to override a widget to display it in a
different language. Who knows what people might want :)
Handling the different language tags should probably be handled by
I18N::LangTags. You can pass it a string ($r-header_in('Language'), and
it will return an array of valid RFC1766-style language tags.
Sorry if it sound like I'm rambling, but I'm just throwing down thoughts
as they pop into my head :)
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Real Widgets and Template Languages
On Tue, 22 May 2001, Gunther Birznieks wrote: What I am really looking for is a library that abstracts and allows widgets to be developed that are tied to an application not to a set of HTML necessarily. I guess I will start by providing an example of what I want based on what we currently do in our Java framework when he use Templating there. I'd like it if someone has developed the same thing in Perl that we could reuse, otherwise, we may need to write this. This sounds very useful and powerful. I've been looking for a project to help out with, and this one sounds interesting to me. Let me know if you want some help developing it, or someone to bounce ideas off... TR THFirst Name:/THTDwidget id=fname//TD THLast Name:/THTDwidget id=lname//TD THComments/THTDwidget id=comments//TD /TR One thing that I think is very important is to let designers have control over the look and feel of the interface. Your widget library should have some mechanism to allow a template designer to specify attributes for a widget (like width, height, colour, etc...). widget id=comments width=100 height=5 color=red - or - widget id=comments attr=width=100; height=5; color=red You can still allow programmers to have control over how the data is verified, and other attributed like maxlength for text fields and such. Of course these attributes will not be useful in every type of widget. ie if the programmer decided that this widget is going to be a text field instead of a textarea, then the above height attribute would be useless, and ignored. Cees
Re: Apache::Session not storing changes to hashref
Apache::Session only does a shallow check of your data structure to see if
it needs to update the database. If you are only changing values deep
inside a hash structure, A::S will not see the changes, and they will not
be saves. The man page recommends adding a timestamp to the tied hash and
updating that on every request (ie $s{_timestamp} = time;).
Cees
On Tue, 22 May 2001, Chris Thompson wrote:
I'm at wits end, I'm hoping someone can tell me what's wrong.
This is Apache 1.3.19, Redhat 6.2, modperl 1.25, apache::session 1.53
and MySQL 3.23.36.
(This is also happening inside HTML::Mason 1.03, but I dont think that has
anything to do with it. I've crossposted to the mason list in case anyone
there has seen this behavior, but what I'm doing isnt really out of the
ordinary, so I dont think it's Mason related)
I've got a hash %s successfully re tied every request. I'm using it to store
a session id and userid with success, so I know it's storing.
Maybe I'm doing too much for A::S but here goes.
I want an entry in the %s hash that is an array of hashrefs
so tied-hash - array - hash.
I'm writing this in wizard style, getting one piece of information from the
client per page. The first step is to get a list of domain names, which I do
and store in @domain.
then I do
my $c=0;
foreach my $dom (@domain) {
my $ref = { 'domainname' = $dom,
'term' = '',
'ns1name' = '',
'ns1ip' = '',
'ns2name' = '',
'ns2ip' = ''
};
$s{regdomains}-[$c++] = $ref;
}
this data is all successfully stored in the session.
We now move to the second page, and if I do a Data::Dumper on %s, I can
actually see the above structure as I envisioned it.
(I'll paraphrase here and not paste the whole dump)
'regdomains' = [
{
'ns1name' = '',
'ns2ip' = '',
'domainname' = 'qwert.com',
'term' = '2',
'ns2name' = '',
'ns1ip' = ''
},
Note that 'term'= '2'.
That's there because before I did the Dumper, I populated the %s with the
data I had on the term. Each term is read from Apache::Request into
@term. (Yes, the orders match)
so I do...
my $c=0;
foreach my $term (@term) {
$s{regdomains}-[$c++]-{term} = $term;
}
Then I do the Dumper. You can see the result above. Term is set, and I've
verified by changing the term per domain name that the data is going in
correctly.
Now, as I understand it, the tie is causing any data written into the hash
to be written to the database.
The problem is that it's not. When I get to my third page I get four fields
per domain for the nameservers and assign into the hash with...
my $c=0;
foreach (@{$s{regdomains}}) {
$s{regdomains}-[$c]-{ns1name} = $nsn1[$c];
$s{regdomains}-[$c]-{ns1ip} = $nsip1[$c];
$s{regdomains}-[$c]-{ns2name} = $nsn2[$c];
$s{regdomains}-[$c]-{ns2ip} = $nsip2[$c];
$c++;
}
I then do a Dumper and get...
'regdomains' = [
{
'ns1name' = 'a',
'ns2ip' = 'd',
'domainname' = 'qwert.com',
'term' = '',
'ns2name' = 'c',
'ns1ip' = 'b'
},
you'll see that term is now empty. I've watched the db, and reading it's
cryptic scrawl, I never see any entries for term.
HELP!
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Real Widgets and Template Languages
On Wed, 23 May 2001, Gunther Birznieks wrote: Hmmm. I had not thought of this because we do not provide this capability now in the Java widget library that we have and we don't really miss it. For color, most UI widgets do not have color. For font and height, I think that most designers don't change this often and if they do, it can be adjusted in the config file ... usually the widgets themselves don't change -- it's the stuff around the forms that do 90% of the time. I guess what I am really thinking about is things like JavaScript Events. The widget would be able to automatically add an onChange JS function to do client side validation of data. But a designer might want to add an onMouseOver to a widget that will display a layer with a hint describing how that field should be filled in. You could just add support for MouseOver Hints to the widget library, but I could probably come up with a bunch of other things a designer might want to change on a widget to get it to do, and look how they want. Cees
Re: That annoying DB guy again... ;-)
On Tue, 22 May 2001, Jonathan M. Hollin wrote: I know you all want me to go away, so I apologise for the noise. Anyway, at http://perl.apache.org/guide/databases.html#Why_Relational_SQL_Databases there is a reference to an Apache::DBI module. I DON'T have this module installed - is this the reason why CGI connects work yet mod_perl requests don't? I wonder... No, that module is not required. Apache::DBI will cache DBI connections for you. It is something you might want to look at after you get your problem fixed. As to Ken's suggestion of trying to access MySQL from the command line using the same user as apache is running as, you could try running the mysql command line interpreter as a different user: mysql -u username -p databasename The -p just means it will prompt you for a password. I would have a good read of the MySQL docs on access permissions. Or try running Apache as a different user that you know has access to the database. Please don't let this discourage you from using mod_perl. It is probably one of those simple mistakes that everyone makes. And if you really can't solve your problem, you could always scrap windows and use Unix instead of scapping mod_perl and using VB ;) Cees
Re: Insecure dependency errors
On Thu, 3 May 2001, Barry Veinotte wrote: [Thu May 3 15:06:57 2001] [error] Insecure dependency in open while running with -T switch at /usr/local/www/vhosts/ad-eagle.com/cgi-bin/ad-eagle/lib/AdEagle.pm line 472. The scripts using the .pm are running under Apache::Registry and have been running fine. Then last night a major upgrade was done to the servers. Now the scripts are dying with this error. None of them are running -T I don't think any on the server are, and know none under Apache::Registry are. Only Apache::Registry scripts are being affected. Anyone have any ideas as to where I could start looking? Check your Apache config files for PerlTaintCheck On, and check all your registry scripts for the -T switch. Also, taint checking is automatically turned on when scripts are run setuid (I don't know if that can affect Registry scripts, but it's probably worth checking the file permissions on all your scripts and modules) Cees
Re: an unusual [job request] + taking mod_perl to the commercialworld
On Sun, 29 Apr 2001, Adi Fairbank wrote: Thanks Gunther, We actually have discussed releasing our entire application open source. I personally would love to release it, being the chief architect, but there are other people involved who have put in a lot of work (directional/advisement/guidance... not coding) who would not benefit nearly as much as I would from it being open source. Also, as a company we have to evaluate what the best option is financially. We are currently a pretty low-budget operation, and if we release it what will prevent someone with deep pockets to come along, take it, and then dump tons of money into marketing it under a different brand name? I'm sure we could devise a license that would prevent such an occurrence, but it would have to be a pretty restrictive license, which would in itself limit the interest in the software. I am in a similar situation with my company. Our main business is building small to medium scale web sites for small businesses. Our customers can build and maintain their websites and email accounts through a web frontend (ie choosing a template, WYSIWYG editor, menu builder, etc...). Everything we do is written in perl with a MySQL or PostgreSQL backend, and I am in the process of mod_perl'ifying most of it. Any new custom jobs that we do are also done in mod_perl. To simplify our development, and to keep our development and design teams separate we have developed a bunch of modules that simplify life in general (a template engine, a DBI wrapper, a form handler, etc...). We have talked about throwing our modules and apps out to the masses, but like most other companies, we are faced with competition. A big part of our marketing push is the easy-to-use tools for managing your website. If we give these tools away to our compeditors, then we loose our advantage in the marketplace. Perhaps once our position is more stable in the market we will be able to contribute back to the community with the work we have done... -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
[OT] Re: Fast DB access
On Thu, 19 Apr 2001, Murali V wrote:
Hi,
If you read the code more deeply, you'll find that the timeit is only
wrapped around select and not around insert.
We've written the insert code so that in the first round you can populate
the database.
You comment out the insert code after the first round and run the benchmark
several times. This would only do select and time select.
Hi Murali,
OK, to start off, I was not specifically aiming my rant at you, I was
replying to someone who had modified your code and was now comparing MySQL
and PostgreSQL, and he was implying that the timings were for inserts and
selects. I took this at face value, and didn't check the code close
enough which I really should have done in the first place.
Connecting this error to an axiom that "Benchmarks are useless" is bad
indeed. Shouldn't we be ironing out errors and runing benchmarks which are
good.
Perhaps I should have said published benchmarks. In your case, you are
using benchmarks for exactly what they are intended for... Creating a
system that closely resembles your application and putting it through it's
paces. What I find dangerous about publishing benchmarks, is that they
are almost always heavily swayed to a specific application, and most of
the time they show what the user wants them to show.
In your original message, you clain to have a bias against Postgres, and
your benchmark shows that bias. I however am a happy user of postgres,
and am therefore biased towards it. I modified your benchmark script
slightly, and I got the following results (I have include a diff of my
changes at the bottom):
postgres
0 wallclock secs ( 0.02 usr + 0.01 sys = 0.03 CPU)
postgres
0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
Whereas if I run it with your version I get the following:
postgres
27 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
postgres
27 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
So what does that tell you about the benchmark? that the postgres part of
this benchmark is useless... It may have given you the answer that you
wanted, but it is misleading to anyone else out there.
This is why there are always flame wars about benchmarking databases (by
the way I think this whole thread has been very civilized and i hope is
stays that way). Invariably the benchmark has missed some critical idea
or optimization which drastically skew the results.
Your recommendation is to pick a DB best suited to your app. But How ??
a) Either by hiring a guru who has seen all kinds of apps with different DBs
who can give you the answer with which we can run
b) Run a benchmark on critical programs which represent you app across
databases and find what performs best.
I've read too much literature on DB features. All DBs have all features
(except MySQL which does not have commit )
You can't make a thing out of DB literature.
What I would recommend is exactly what you have done in this case. Get
access to any and all the systems that you feel may do the job for you ,
and try them out. Browse the web for other users experiences, but don't
use other peoples benchmarks, because the odds are good that they are
wrong... Create your own, or modify an existing one, and scrutinize
exactly what it is doing. And if you want to share your results with
anyone else, tell them what you choose in the end, and why. Tell them you
choose database x because it did this and this for you. Don't say
database y is a piece of crap, so we went with database x.
But whatever you do, don't choose your database based on other peoples
benchmarks (that is all I'm trying to say, and I guess I didn't
say it clearly enough)
When I first read your message, I tucked it away somewhere, so I could
reference it again in the future, because I was interested in the MLDBM
work that you had done, and I thank you for that. But it also made me
think that maybe I shouldn't be using Postgres, because your results were
so poor (only for a second or too though :). But I'll bet that a lot of
people who have never used postgres before are now less likely to download
it and try it out for themself, because a benchmark swayed them away from
it. That sounds like a good closer, so I'll stop it there :-)
Cees
Here is the diff of my changes and a quick comment on why your way kills
the performance of postgres
***
*** 124,131
$i_ip = int(rand(20));
@row_ary = $dbh-selectrow_array("select crr from benchmark where
! rtrim(pub) = 'pub$i_pub' and rtrim(size) =
'size$i_size' and
! rtrim(type) = 'type$i_type' and rtrim(ip) =
'ip$i_ip'");
}
};
--- 124,131
$i_ip = int(rand(20));
@row_ary = $dbh-selectrow_array("select crr from benchmark where
! pub = 'pub$i_pub' and size = 'size$i_size' and
! type =
Re: Fast DB access
On Thu, 19 Apr 2001, Differentiated Software Solutions Pvt. Ltd., wrote: I get a feeling that the point we were trying to make is going to be missed. MLDBM is not a bad alternative to databases under specific conditions !! That point was definately not missed by me, and I have learned something from your efforts. I have used gdbm in the past with great success, and will look into MLDBM with any new projects that may benefit from it. I hope this thread won't keep you from contributing to this list in the future... Cees
[OT] Re: Fast DB access
On 18 Apr 2001, Clayton Cottingham aka drfrog wrote:
[drfrog]$ perl fast_db.pl
postgres
16 wallclock secs ( 0.05 usr +0.00 sys = 0.05 CPU) @ 400.00/s (n=20)
mysql
3 wallclock secs ( 0.07 usr +0.00 sys = 0.07 CPU) @ 285.71/s (n=20)
postgres
17 wallclock secs ( 0.06 usr +0.00 sys = 0.06 CPU) @ 333.33/s (n=20)
mysql
3 wallclock secs ( 0.01 usr +0.01 sys = 0.02 CPU) @ 1000.00/s (n=20)
correct me if im wrong but if fast_db.pl is
working right
first set is insert
second set is select
I am mad at myself for getting dragged into this, but I couldn't help
myself...
You are crippling postgreSQL by doing a tonne of inserts with a commit
after each statement. This completely misses the fact that postgreSQL is
transaction based whereas MySQL is not. Turn off AutoCommit and do a
commit at the end of the insert loop.
Also, if your selects are taking just as long as your inserts then you
must have other problems as well. Did you set up any indeces for the
columns of your table, or is that considered "optimizing the database" and
therefore not valid in your benchmark?
Benchmarks like this are pretty much useless (actually 99% of all
benchmarks are useless).
Use the database that best fits your needs based on the features it
supports, and the experience you have using it. If you find your database
is too slow, look into optimizing it because there are usually hundreds of
things you can do to make a database faster (faster disks, more ram,
faster CPU, fixing indeces, optimizing queries, etc...).
Don't pick a database because a benchmark on the web somewhere says it's
the fastest...
Sorry for the rant, I'll go back to sleep now...
Cees
find attached the modified ver of fast_db.pl
i sued to conduct this test
comp stats
running stock rpms from mandrake 7.2 for both
postgresql and mysql
3.23.23-beta of mysql and
7.02 of postgresql
[drfrog@nomad desktop]$ uname -a
Linux nomad.localdomain 2.2.18 #2 Tue Apr 17 22:55:04 PDT 2001 i686 unknown
[drfrog]$ cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 257511424 170409984 87101440 24219648 96067584 44507136
Swap: 2549432320 254943232
MemTotal:251476 kB
MemFree: 85060 kB
MemShared:23652 kB
Buffers: 93816 kB
Cached: 43464 kB
SwapTotal: 248968 kB
SwapFree:248968 kB
[drfrog]$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family: 6
model : 3
model name: AMD Duron(tm) Processor
stepping : 1
cpu MHz : 697.535
cache size: 64 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp: yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 psn mmxext mmx fxsr 3dnowext 3dnow
bogomips : 1392.64
i will recomp both the newest postgresql and mysql
not using any optimizing techs at all i'll post the
config scripts i use
On Tue, 17 Apr 2001 18:24:43 -0700, clayton said:
Matt Sergeant wrote:
On Tue, 17 Apr 2001, Differentiated Software Solutions Pvt. Ltd., wrote:
H/W : Celeron 433 with 64 MB RAM, IDE HDD using RH 6.1, perl 5.005,
Postgres 6.5.3
This is a very very old version of postgresql. Try it again with 7.1 for
more respectable results.
im very glad to see this thread
i wanted a good benchmark for postgres and mysql
{i hope to transpose the sql properly!}
i do have 7.1 installed and it is very sweet
ill report back when i rerun under postgresql at the very least
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: from the quick hacks department... x-bit controls mod_cgi
On Thu, 12 Apr 2001, Tim Bunce wrote:
On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
In an .htaccess, I place:
Options +ExecCGI
PerlFixupHandler "sub { -f $_[0]-filename and -x _ and
$_[0]-handler(q{cgi-script}) }"
Now any executable file in this directory (or below) is processed with
mod_cgi. Any non-executable file is processed with whatever the MIME
engine came up with before.
OK, too cool to not pass on. :)
Except that I think you'll find that string is being recompiled for
each request - slow and leaks memory. The principle is good though :)
Can you briefly explain why it leaks memory?
I have been playing with Apache::Leak and Devel::Leak trying to figure out
what is happening when Perl code leaks memory, but I haven't got my head
around it yet...
Also, a more general question to the list. How reasonable is it to assume
that most of the more standard modules on CPAN don't leak memory when used
in a mod_perl environment? For example DBI (not to pick on you Tim),
Data::Dumper, HTML::Parser or MD5 just to name some of the more common
modules. Are there any modules that I should stay away from when using
mod_perl?
- Cees Hek
Apache::Request problem (possible bug)
Either I've found a problem with Apache::Request, or I don't know what I'm
doing :)
Setting variables with $r-param() doesn't seem to work for array
references. ie the following line from the man page doesn't work
correctly
$r-param('foo' = [qw(one two three)]);
When you look at foo afterwards it returns the string 'ARRAY(0x8c04fd8)'
instead of an actual reference to the array.
I have include a basic handler that demostrates this on my machine
(Apache/1.3.17 mod_perl/1.24 perl 5.005_03)
package Apache::Test;
# File: Apache/Test.pm
use strict;
use Apache::Constants qw(:common);
use Apache::Request ();
sub handler {
my $r = new Apache::Request(shift);
$r-content_type('text/html');
$r-send_http_header();
my @list = $r-param('list');
$r-param('newlist' = [qw(one two three)]);
my @newlist = $r-param('newlist');
my $list = join ', ', @list;
my $newlist = join ', ', @newlist;
print "EOM";
HTML
BODY
list - $listBR
newlist - $newlistBR
BR
FORM
SELECT NAME="list" MULTIPLE
OPTIONBlue
OPTIONGreen
OPTIONRed
OPTIONYellow
/SELECT
INPUT TYPE="submit"
/FORM
/BODY
/HTML
EOM
return OK;
}
1;
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Long waits on SQL Stored Procs. Should I use chained contenthandlers?
On Mon, 2 Apr 2001 [EMAIL PROTECTED] wrote: I need to run some stored procedures that take upwards of a minute to generate result sets. Ok, thats grand but I dont want the browser to sit there and twiddle. I'd like to display an animated gif. Simple. Right? I hope. Why can't you just display your animated gif on a page with a refresh tag that loads the real page with the query in it. A refresh meta tag doesn't have to reload the same page again, you can redirect it to another URL. Your gif would be displayed, and you query would start right away. You have to make sure that you don't send out any data from your query script until you are ready to display the entire thing. The browser will not clear the screen until it receives some data from the server. The only other issue here is browser timeouts. If the page takes too long to display, the browser may drop the connection, but I've found that if a browser makes a connection, it will wait for a 'long' time for data to show up. I don't have any numbers, but it would be trivial to test. This method is great to stop people from hitting a link repeatedly if a page doesn't load right away. I've included a simple HTML page that we use to generate some reports that take up to 30 seconds to display Cees Hek html head meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" META HTTP-EQUIV="REFRESH" CONTENT="0; URL=reports.cgi?sessionid=?" /head body marginheight="0" marginwidth="0" topmargin="0" leftmargin="0" bgcolor="#FF" table width="100%" height="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#FF" align=center tr td align="center" valign="center" font face="verdana,arial,helvetica" size=4 color=red Please wait while creating reports.../font /td /tr /table /body /html
Re: Apache::Session::Postgres Segmentation Fault Addendum
On Thu, 29 Mar 2001, Victor Michael Blancas wrote:
I'm using Apache::Session::Postgres with Apache::ASP.
I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the
end of the script. When I comment out the the $dbh-disconnect however, I
don't get any errors. Having a script without a $dbh-disconnect at the
end is wrong isn't it. Anyone encountered this before?
I just tested it as a simple perl script on the command line. I'm still
getting a core dumped Segmentation Fault whenever I do a disconnect at the
end of the script.
I have had this happen to me as well. You have to make sure that your
session is untied, before the database is disconnected.
What I found was that after pulling some data out of the session, it was
still TIE'ed to the session object.
ie I with the following
my $userid = $session-{userid};
$userid is pointing into the tied hash, so if the database disappears, and
you try to access $userid, you will get a segfault.
The following program demonstrates this on my system
use strict;
use Apache::Session::Postgres ();
use DBI ();
my $dbh = DBI-connect('DBI:Pg:dbname=testdb', undef, undef,
{ RaiseError = 1, AutoCommit = 0 })
or die "connect: Can't connect to database: $DBI::errstr";
tie my %s, 'Apache::Session::Postgres', undef,
{ 'Handle' = $dbh, 'Commit' = 1 };
# Put something in the session and then take it out again
$s{'testing'} = 'Something to put in the session';
my $test = $s{'testing'};
# disconnect from database
$dbh-disconnect;
# Accessing $test again will cause a segfault
print $test, "\n";
I realize that this is bad programming style, since I should untie %s
before I disconnect $dbh, and doing that stops the segfault (it also means
that $test will be blank if it is accessed after the untie). But I don't
think that this should cause a segfault in the first place.
It sounds like there is a problem in Apache::Session::Postgres but I
haven't had time to search for it...
Cees Hek
Re: perl session management
On 27 Mar 2001, tom joseph wrote: Hello there.. Could u suggest a way to update a session variable. At present it is not possible for me to update a session variable from any other page. I thought it would be automatically updated when i do a new insertion into the session variable which in my case is a hash. Is there any other way. Could anyone please help. I am using the module Apache::Session::MYSQL. You don't give us much to go on, but I'll give it a shot. I seem to remember that Apache::Session only does a very quick check to see if anything has changed in the session object. Here is an excerpt from the Docs: Note that Apache::Session does only a shallow check to see if anything has changed. If nothing changes in the top level tied hash, the data will not be updated in the backing store. You are encouraged to timestamp the session hash so that it is sure to be updated. So if all you are doing is changing one of the values in your hash, then Apache::Session will not see a change and will not rewrite the entry to the database. Cees
Re: The right way to do authentication with mod_perl
You should really have a look at Apache::AuthCookie. This module does pretty much exactly what you are looking to build. I think it'll even handle your guest logins. If you are still keen on rolling your own module, this module will give you some great hints on how to write an Authentication Handler... Cees On Sun, 18 Mar 2001, Issac Goldstand wrote: I've been self-debating a small issue for a small project that I'm developing, and thought I'd pass it on to see if I can get any feedback from the experts in the field: I have a pair of login/logout CGI scripts on a machine that I recently "bumped" from mod_cgi to mod_perl. They set/removed a cookie that as a key in Jeffery Baker's wonderful Apache::Session module, which I used as a base for my own authentication module (and if Jeffery is reading this, I'd love your feedback about it...). Now, since I am using mod_perl, I've set up my module to be pre-loaded to keep a persistant connection to my session database (the connections to the authentication [via user/password] database is only done in the login script). It seems to me that I _ought_ to try to squeeze a bit more out of mod_perl by assigning a handler during some stage of the server request to do the cookie authentication and then, instead of my scripts checking with the authentication module, I can set an %ENV variable with the authentication results, for later parsing by the scripts. So, firstly, where is the best place to put the handler? Logic would suggest the _authentication_ stage, of course, but I'm still a tiny bit too newbie too know exactly how I'd have to set up the .htaccess ..htpasswd files, let alone what kind of response I have to send back to the server. (Links to the mod_perl Guide are fine for answering this. I have, truth to tell, not quite finished reading the whole thing, but I have people pressuring me to fix the login buisness which, as a result of moving to mod_perl, is now quite a mess so I'm doing the unthinkable and asking even though I have not read every bit of documentation :-}) Secondly, there are one or two scripts that have a "guest" login. The way this works, in short, is that authentication is pre-generated and coupled with other "challenge tokens", which are all passed as part of the URI. This would obviously have to bypass the "normal" login/authentication handlers. The solution which leaps to my head is doable, if a bit crude: make a special aliased directory for guest-login-related scripts (actually only the original authentication [eg, first request] has to be via URI; I can switch to normal cookie based beyond that). But I'd really like to hear what people who've been developing mod_perl 'application's for more then just a few weeks would say. Thanks, Issac BTW: For the experts here, I must say that I'm really impressed with the mod_perl mailing list in general. I find that I'm learning almost as much from here as I do from the guide and manpages, and I am most impressed at the general attitude towards newbies. I've been a newbie, and a regular, on many technical mailing lists, but almost never seen that John Q. Newbie got decent attention on most of them. I just felt that gratitude ought to be expressed where it is due. Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
Re: Authentication handlers
On Mon, 5 Mar 2001, Daryl Campbell wrote: Cees suggestion seems to unlock part of the browser behaviour puzzle that we are trying to solve to meet the following requirements for a PerlAuthenHandler: *URL based session handling if cookies not enabled, *LDAP authentication, *Force reauthentication if given inactivity period passed, *Maintain state information in main memory, no DBI store required. So now our session state information is "Time_last_accessed and Next_realm", or generate the realm based on current time if inactivity period lapsed. Assuming that we are sending an AUTH_REQUIRED when inactivity period is lapsed. Forget about Realms and AUTH_REQUIRED headers if you want to do the above. You can use Apache::AuthCookieURL to handle passing session IDs to and from the browser (Requirement #1). You will have to override 2 functions (writing them should be very straight forward): authen_cred() which will verify the credentials passed from the login form (using LDAP in your case, Requirement #2) and create a new session for them. And authen_ses_key() which will verify that the users sessionID is still valid, or if it needs to be expired (Requirement #3, if you return nothing from this function, Apache::AuthCookieURL will redirect the user to the login page automatically). Now you should have a mechanism that handles your session keys for you, but you still need to store the session data somewhere. I have used Apache::Session with good success, but there are others available as well. I would be careful about storing session info in memory (Requirement #4). If your server gets hit hard, you could very quickly run out of memory. You would have to put some memory limits im place, and that means saving inactive sessions to disk. It really depends on your setup, and how many concurrent users you are planning to have. 1. If you aren't going to have many users, your machine won't be that busy, so you might as well save to a database. 2. If you are going to be very busy, you will probably have too many sessions active to be able to store them in main memory. 3. If you are really busy, but you don't have much to store in the session, you might as well encrypt the data and send the info in the cookie/URL instead of passing the sessionkey. But if you still want to do it, you could use IPC::Shareable (an old version of Apache::Session supported this module, but it has been removed since). There is also IPC::Cache and probably others as well. Go easy on me, it's my first mod_perl posting but have been chewing on the mod_perl guide, eagle book, and the mailing list archives. Well, this is only my third message to the list ;) -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
Re: Authentication handlers
On Sat, 3 Mar 2001, Kiran Kumar.M wrote: hi , i'm using mod_perl authentication handler, where the user's credentials are checked against a database and in the database i have a flag which tells the login status (y|n), but aftr the user logs out the status is changed to n , my problem is that after logging out if the user goes one page back and submits the browser sends the username and password again , and the status is changed to y . Is there any means of removing the username and password from the browsers cache. I'm assuming you are using Basic Authentication here... I haven't used Basic Authentication in a couple years now, but I seem to remember that you can specify a 'Realm' in which the username and password is valid. If you change this realm when the user logs out, then they will be prompted for their username and password again. So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. -- Cees
Re: Authentication handlers
On Sun, 4 Mar 2001, Pierre Phaneuf wrote: Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. Well, since the only requirement is that it is different from the last Realm you sent, (ie it doesn't need to be unique across all users), you could easily use the date and time. Something like Secure Area (Mar 5, 2001 10:51:02) This would have the side effect of also telling you when the user logged in. You would have to check the RFC to see what the size limit is on a Realm. -- Cees
Re: mkdir function syntax
On 27 Feb 2001, Chris Jensen wrote:
here is my code:
8 $query = new CGI;
9 $ProjectNumber= $query-param("ProjectNumber");
10
11 $makeDirectoryDocs = "../WebSites/mch.nvisionusa.net/docs";
12 $makeDirectoryImages = "../WebSites/mch.nvisionusa.net/docs";
13
14 MKDIR ($makeDirectoryDocs$ProjectNumber);
The problem is with the way you are trying to join 2 strings together.
One of the following should work for you:
mkdir ("$makeDirectoryDocs$ProjectNumber");
mkdir ($makeDirectoryDocs.$ProjectNumber);
mkdir (join '', $makeDirectoryDocs, $ProjectNumber);
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
