Re: [mp2.0] wrong crypt behavior
On Thu, 10 Oct 2002, Ask Bjoern Hansen wrote: On Fri, 6 Sep 2002, [iso-8859-2] Tomá¹ Procházka wrote: Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line Did anyone figure this out? Rick Bradley did, but only posted it on the dev@ list where I didn't catch it. It's a bug in glibc 2.2.5 on linux: http:[EMAIL PROTECTED]/msg85673.html - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
[OT] Re: Testing mod_perl app on Windows
FYI: MS Windows .NET server (which is the XP server equivalent) is available for beta. Find out at windowsbeta.microsoft.com Issac - Original Message - From: Adam Nelson [EMAIL PROTECTED] To: 'Ken Y. Clark' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 11, 2002 4:07 PM Subject: RE: Testing mod_perl app on Windows ME is just windows 98 with some bells and whistles. If you want server, then win2k Server is still the standard (XP is only for workstation/desktop). I think mod_perl/Apache will run fine on ME,2000,XP,and even 98. But for real server environment, the choice is 2000 Server. -Original Message- From: Ken Y. Clark [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 8:32 AM To: [EMAIL PROTECTED] Subject: Testing mod_perl app on Windows My boss has asked me to pick up a Windows box so that I can test my application using the standard browsers on that OS. OK, I can see how it is a Good Thing to make sure that those people unfortunate enough to use Windows are able to use my application without errors. But I also had another idea: As I'm trying to make sure my code is platform-neutral, I'd like to try installing everything on the Windows platform as some people who download my app might try to do this. Not having touched Windows in about 3 years, all the different products really confuse me. When I go to the local PC store to pick up a box, what should I ask for? Windows 2000, ME, XP? Is there a specific XP server, or can I install Apache/mod_perl on the standard desktop OS? ky
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
On Wednesday, 2002-10-09 at 18:22:24 -0400, Steve Grazzini wrote: On Wed, Oct 09, 2002 at 02:43:18PM -0700, Paul wrote: The company is making us migrate (some baloney about being legally vulnerable because we're using open source) If they won't let you use open-source tools, then the answer is definitely yes. (Perl is open-source.) As are all modules on CPAN. If they really mean this, you will have to rewrite in a language that has a closed-source compiler, using only modules that are not available in source. Do not use any code examples, too, just to be sure ... =:-| If you want to be sure you are implementing what *they* want, you better ask *them* where Open Source stops. Steve's point about perl being open source may be important for your career ;-) (As in Career-limiting move) And migrating from a relational database to LDAP might not be as obvious as... oh well. Depending on what you do, it may not even be suitable. LDAP organizes data hierarchically. It hangs attributes off objects. Generally, LDAP databases are slower than RDBMSes. HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... |
Re: perl script not reloading
Hi there, On Sat, 12 Oct 2002, Michael Grant wrote: I did this and it still doesn't reload the script. I added it just after the LoadModule: LoadModule perl_modulelibexec/apache/libperl.so PerlInitHandler Apache::StatINC It's a single main script, not a module. Have you tried perldoc Apache::StatINC ? 73, Ged.
CGI parameters appear to be doubled on 8 bit chars...
Just wondering if anyone has seen this problem before, or has a general
solution to it. Basically what we see, is that with some submitted forms,
usually with 8 bit data, the POST parameters passed become 'doubled'. The
problem is that we have a loop like this to gather out all the parameters
early on in our handler code.
foreach my $Key ($R-param) {
my ($UKey, UParam) = ($Key, $R-param($Key));
$CGIState{$UKey} = scalar(UParam) 1 ? \@UParam : $UParam[0];
}
The result is that we end up with an array reference for every parameter,
instead of a scalar value. And we can't just always take the first value,
because multi-select list boxes also return array values, and we don't know
at this stage in the code what type of form element each param comes from.
In general, the values are the same, except where there is 8 bit data, in
which case the 2 versions are different. Here's an example of what we see:
$VAR1 = {
'LastScreen' = [
'/MR-@0,324,',
'/MR-@0,324,'
],
'Subject' = [
'Blah blah blah',
'Blah blah blah'
],
'Message' = [
'#8216;blah blah#8217; blah blah #8216;blah blah#8217; blah.',
'91blah blah92 blah blah 91blah blah92blah.'
]
}
(The 91 etc are highlighted when using 'less', so I presume that probably
means it's hex code 0x91)
So it seems somewhere the 8 bit data is coming as both HTML entity versions,
and the raw 8 bit data version. I'm not sure if this is IE or mod_perl doing
this, though I'm guessing it's IE.
So in general, my questions are:
1. Have people seen this before, and how do you generally deal with it?
2. Actually how do you handle in general 8 bit data? How do you know which
charset it's coming as?
3. Is there any documentation anywhere on why this is happening? Who is
sending the two versions? How to detect it?
Any help or pointers on dealing with these issues would be appreciated.
Thanks
Rob
Re: OT: Are things really this bad?
On Saturday, 2002-10-12 at 11:50:12 +0100, Dave Hodgkinson wrote: Todd Finney [EMAIL PROTECTED] writes: Over here, the barometer looks like: For what it's worth, here is the major Freelancer/Professional Services site in Germany: http://www.gulp.de/kb/tools/gulpometer.html If you want to have some statistics (in German!), go to http://www.gulp.de/kb/tools/trend.html Enter Web and Perl, and set the first oder to und. Click on Analysieren. You'll get project inquiries, project inquiries by German zipcode region, Prozentuale Verteilung der Stundensätze (percentage distribution of hourly rates), some others of less interest, and at the end age distributions for the two keywords and over all freelancers at Gulp and all project inquiries at Gulp. Makes me feel old. I'm 48... If you don't want to do that, the hourly rates are: Web 72,22 EUR Perl69,29 EUR All Freelancers 72,72 EUR All Inquiries 75,25 EUR 1 EUR = 0.9860 US$. The UK site says the going rate overall is 19 Pounds. That is 30 EUR or US$. No wonder I'm meeting lots of British people when I visit clients. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... |
Re: Apache::DBI and CGI::Application with lots of modules.
Hi,
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't true. It says that
if I have this situation, I will get a warning. I am not getting any
warnings, but I am getting this behaviour with my search queries getting stuck
The only thing I do is again, copied from the perltoot
package Searches;
use strict;
use Carp;
use vars qw($dbh);
use gentimeid; # generate time id based
use Calc_Price; # get totals
use warnings;
# use DBIx::XHTML_Table; # maybe later
use QueryPrint;
#use Data::Dumper;
# These searches are restricted to user level searches, there will be a
admin level search for
# managment reports
$dbh = db_connect();
# requires a $q query object to be init.
sub new {
my $self = {};
my $proto = shift;
my $class = ref($proto) || $proto;
$self-{queryobject} = undef;
$self-{isDomestic} = undef;
$self-{isInternational} = undef;
$self-{isShippingSame} = undef;
$self-{CustIsInserted} = undef;
$self-{OrderIsInserted} = undef;
$self-{CustNum} = undef;
$self-{OrderNum} = undef;
bless ($self, $class);
return $self;
}
sub queryobject {
my $self = shift;
if (_) { $self-{queryobject} = shift }
return $self-{queryobject};
}
Other stuff not used yet
sub LookupOrder {
my $self = shift;
my $q = $self-{queryobject};
my $output = '';
my $hasparameter = 0;
... Build a query from CGI.pm vars passed in though queryobject
...
$order_name_qu .= ORDER BY $orderby ; # the query string is here
if ($hasparameter == 1) { # if something was filled in the search form
my $sth = $dbh-prepare($order_name_qu) or confess(Main search
failed $order_name_qu);
$sth-execute() or confess(Main search failed $order_name_qu);
my $headers = $sth-{'NAME'};
my rows= $sth-fetchall_arrayref();
my $resulthtml = new QueryPrint(ResultSet = rows,
Action = 'customer',
ColumnList = $headers);
my $html = $resulthtml-SetAction(); # sets a template type in the
QueryPrint module
$output = $resulthtml-QueryPrint();
$sth-finish();
#warn QUERY - $order_name_qu;
undef rows;
undef $resulthtml;
undef $order_name_qu;
return $output;
} else {
return no query to do;
}
Then this is all called from my CGI::Application module
sub customer_display{
my $self = shift;
my $q = $self-query();
my $customersearch = new Searches();
$customersearch-queryobject($q); # set the query
my $header = parse_header($self);
return $header . $customersearch-LookupCustName();
}
So going nuts now, where is the problem? My QueryPrint module is pretty
much the same, so if this is ok, it should be as well.
Thanks,
Eric
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: CGI parameters appear to be doubled on 8 bit chars...
$VAR1 = {
'LastScreen' = [
'/MR-@0,324,',
'/MR-@0,324,'
],
'Subject' = [
'Blah blah blah',
'Blah blah blah'
],
'Message' = [
'#8216;blah blah#8217; blah blah #8216;blah blah#8217; blah.',
'91blah blah92 blah blah 91blah blah92blah.'
]
}
If you know the fields that are supposed to have select
lists on them (e.g., select_list{qw(field field field)} = 1)
then you can walk down the list and compare ref $contents with
$select_list{$name}. If both are true then it's a list, else
it's 8 bit junk in two fields; both false gives you a normal
field.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
serving large files with access controls
Suppose I have a typical proxied mod-perl setup and I have a large (~ 650 MB) file I'd like to provide authenticated access to. The mod-perl server will be doing the authentication, but for performance considerations I'd like the proxy server to serve the file directly instead of having the mod-perl server first forward the file to the proxy. Is there a way to do this so that access to the file would be _impossible_ unless the user is authenticated by the mod-perl server? I am looking for a solution that can guarantee that there is no way to circumvent the authentication process. I can think of solutions where the probability that users can access the file without authenticating can be made very small, but I am looking for an absolute guarantee. Regards, Erik Rantapaa [EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Re: serving large files with access controls
Is there a way to do this so that access to the file would be _impossible_ unless the user is authenticated by the mod-perl server? I am looking for a solution that can guarantee that there is no way to circumvent the authentication process. I can think of solutions where the probability that users can access the file without authenticating can be made very small, but I am looking for an absolute guarantee. Impossible, no. If the proxy server can handle FTP then one way is to have the source directory mods at 0711. That requires knowing the file name to get it; no listings w/o read access. After that you can have the web server, say, symlink a file with some temp name and redirect the user to the ftp server. Net result is that the proxy handles an ftp request for a name that is temporary to the download and hard to guess. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
*They* don't know what they mean, but we're getting a variance for Perl (supposedly). No such luck for mysql or apache --- Lupe Christoph [EMAIL PROTECTED] wrote: On Wednesday, 2002-10-09 at 18:22:24 -0400, Steve Grazzini wrote: On Wed, Oct 09, 2002 at 02:43:18PM -0700, Paul wrote: The company is making us migrate (some baloney about being legally vulnerable because we're using open source) If they won't let you use open-source tools, then the answer is definitely yes. (Perl is open-source.) As are all modules on CPAN. If they really mean this, you will have to rewrite in a language that has a closed-source compiler, using only modules that are not available in source. Do not use any code examples, too, just to be sure ... =:-| If you want to be sure you are implementing what *they* want, you better ask *them* where Open Source stops. Steve's point about perl being open source may be important for your career ;-) (As in Career-limiting move) And migrating from a relational database to LDAP might not be as obvious as... oh well. Depending on what you do, it may not even be suitable. LDAP organizes data hierarchically. It hangs attributes off objects. Generally, LDAP databases are slower than RDBMSes. HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be | | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... | __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Apache::Reload - patch - fixes problems with using dynamic @INC
I started using a dynamic INC (set up in a TransHandler), and discovered
that Apache::Reload (v0.07) was not doing its job correctly in that case.
Note, changing INC in a transhandler won't have the desired Apache::Reload
effects unless the PerlInitHandler for Apache::Reload is placed in a
Location section of httpd.conf.
The following patch corrects this, though it adds a few extra stat() calls
if the module is found at the end of INC instead of near the beginning (as
mine are). You could make this behavior an optional one for strange folks
like me :). Oh, I just added that to the patch manually:
PerlSetVar ReloadDynamicInc 1
...will enable this INC-scanning behavior. I think I hacked the patch
correctly :)
Note, if a module is loaded with one INC, then on a subsequent request,
INC changes such that the module would be not-found, the module is not
removed from memory. If you do that and use it from a script (served when
INC doesn't have the module), you'll get erratic behavior - it'll work fine
sometimes and error out other times. So don't do that., as a wise man
said. Instead, make sure INC always has the right libs for your script -
test from a freshly-started server to be sure.
Separate from this strange Dynamic-@INC use case, there's another bug in the
release version of the module: if you moved a module from one INC dir to
another, the INC loop at the top of handler() would not find the file, as
it was looking for inc-dir/full-path-name instead of
inc-dir/relative-path-name. This patch should fix this too, whether
ReloadDynamicInc is used or not.
I haven't tested this with wildcard settings or ReloadAll.
Enjoy,
Randy
--- Reload.pm Sat Oct 12 16:22:02 2002
+++ Reload.pm.new Sat Oct 12 17:08:07 2002
-108,35 +108,40
while (my($key, $file) = each %Apache::Reload::INCS) {
local $^W;
warn Apache::Reload: Checking mtime of $key\n if $DEBUG;
my $mtime = (stat $file)[9];
-unless (defined($mtime) $mtime) {
-for (INC) {
-$mtime = (stat $_/$file)[9];
-last if defined($mtime) $mtime;
-}
-}
+
+my $found = $file;
+if( $r-dir_config(ReloadDynamicInc) || !$mtime ) {
+# seek out the file in INC.
+my $mt;
+for (INC) {
+$mt = (stat $_/$key)[9];
+$mtime = $mt, $found = $_/$key, last if defined($mt)
$mt;
+}
+}
+
warn(Apache::Reload: Can't locate $file\n),next
unless defined $mtime and $mtime;
unless (defined $Stat{$file}) {
$Stat{$file} = $^T;
}
-if ($mtime $Stat{$file}) {
+if( $found ne $file || $mtime $Stat{$file} ) {
delete $INC{$key};
if (my $symref = $UndefFields{$key}) {
#warn undeffing fields\n;
no strict 'refs';
undef %{$symref};
Re: serving large files with access controls
We talked about this limiation of the dual setup before. There is no solution publically available. But you can try this: 1) check http://modperl.home.att.net or similar cookie-based ticketing system. 2) write a ticket-client module in C and load it into the proxy server (I have one based on libapreqs). 3) you can use the same ticket issuer mod_Perl module in the server machine, or any language as far as it can generate a valid cookie. 4) then serve the large file directly via the proxy server. Peter - Original Message - From: Erik Rantapaa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 13, 2002 12:54 PM Subject: serving large files with access controls Suppose I have a typical proxied mod-perl setup and I have a large (~ 650 MB) file I'd like to provide authenticated access to. The mod-perl server will be doing the authentication, but for performance considerations I'd like the proxy server to serve the file directly instead of having the mod-perl server first forward the file to the proxy. Is there a way to do this so that access to the file would be _impossible_ unless the user is authenticated by the mod-perl server? I am looking for a solution that can guarantee that there is no way to circumvent the authentication process. I can think of solutions where the probability that users can access the file without authenticating can be made very small, but I am looking for an absolute guarantee. Regards, Erik Rantapaa [EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
ANNOUNCE: Mason 1.15
This release is all about bug fixes. Basically, %filter blocks have been a bit borked in various ways (different in different releases) since 1.10, and now they should be in good shape. There were a number of test failures reported over the past several releases, almost of which were actually problems with the tests, and we think we've now taken care of those too (although I'm sure someone using Win32 will find some new weird bug for us ;) Finally, the docs in 1.14 had a number of bad links in the HTML versions, as well as some buglets in the POD. This should also be resolved. The goal for 1.1x is now to become as stable and well-documented as possible. We will not be adding any new large features, and small ones will have to either extremely well-contained or extremely well-justified. The next couple releases will aim to A) improve the docs, particularly focusing on a revamp of the Admin guide in regards to configuring Masona and B) improve performance wherever possible, and of course C) fix any remaining bugs. Eventually, we'll fork the code base again and start breaking things in preparation for an eventual 1.20 (or maybe some other version number cause we might get to 1.20 just by small bugfix/doc/performance releases), which will incorporate new features such as .NET compliance, full support for _all_ XML specs, and a special NP-problem solving module, plus a brand new set of ginsu knives. 1.15 October 14, 2002 [ BUG FIXES ] - Fixed a number of problems with filters: -- They didn't see changes made to %ARGS (they were seeing a copy). -- They couldn't see any variables declared in %args blocks. -- The presence of a filter caused a call to $m-flush_buffer, breaking redirects. - Added a number of tests for filters (*cough*). - Fixed broken links and other bugs in the POD and HTML versions of the docs. - Fixed test failures when running as root. These failures were not reflective of bugs in Mason, simply problems in the tests or test setup. Now we skip the tests for end user installs (we still run them during development, never fear). - HTML::Mason::Request contained code that caused an error when using the CPAN shell's r command. -dave (whose mind is apparently blown after several hours too many of Dance Dance Revolution earlier this evening) /*== www.urth.org we await the New Sun ==*/
