Re: kylix: rad!
Hi all, brian moseley wrote: have you folks seen kylix? http://www.borland.com/kylix/ And have you seen KDevelop ? http://www.kdevelop.org and also http://dot.kde.org/992083107/ http://dot.kde.org/986594487/ So there is already a basic Perl support in KDevelop 3 (codename Gideon)... Regards, -- Christian
Re: kylix: rad!
On Sun, 13 Jan 2002, Daniel Aldham wrote: Slashdot and Freshmeat ran a story on the weekend about the Borland/Kylix license. Pretty draconian stuff. that's where i heard of it.
Re: RFC: Exception::Handler
One of the things I don't like about traditional try/catch handling is
that it doesn't allow for class level programming. You need to allow
any subroutine to try/catch exceptions (die). It's also nice to
notify any object in the stack that there is an unhandled exception
passing through its code.
I'm afraid I don't get it - isn't it what the finally functionality
in Error.pm (CPAN) does ?
try {
stuffThatMayThrow();
} finally {
releaseResources();
};
This eliminates a lot of explicit
try/catches.
Well, destructors are of some help too in that issue.
(not lighting up a flamewar, just trying to understand the issues - I
don't know much about Aspects, but I find exception handling with
Error.pm a breeze, even for big projects)
--
Tout n'y est pas parfait, mais on y honore certainement les jardiniers
Dominique Quatravaux [EMAIL PROTECTED]
Ticket systems
Hello, I'm on a mission ta make a web-site that uses cookies for user log-in and log-out. First I'd like to know which one you suggest - Ticket system from Eagle book or Apache::AuthTicket. I know that Apache::AuthTicket is based on Eagle book's version, but it seems little more advanced. And now second problem. Has anyone modified one of these modules so, that when user first enters the site he will get a cookie immediately (with random generated ID) and can walk around there. And if he logs in then the cookie gets modified accordingly (saying that user is logged in). Here's the situation. I must make a site for insurance company. User can browse the site and see which offers he can get, if he wants to make a deal only then he must log in. But all the data that is calculated must be stored in dbase waiting for user to log in, so system can then, err, bind this temporary data with current user. But of course user can log in anytime he wants - even between different calculation steps. Any ideas are welcome. Rgds, Viljo
Re: Ticket systems
I am using Apache1.3.22/mod_perl1.26 with mod_usertrack.c
from httpd.conf
#User Tracking
LoadModule usertrack_module libexec/mod_usertrack.so
AddModule mod_usertrack.c
CookieTracking on
SetEnvIf Request_URI (\.gif|\.jpeg|\.js|\.css)$ junk
CustomLog /usr/local/sites/dev/logs/clickstream
%{cookie}n|%H|%m|%f|%U%q|%{User-agent}i|%{%m/%d/%Y %H:%M:%S}t env=!junk
Along with a cron job and MySQL to gather the Website Statistics
But on this site, I also have say a Admin Section or a WWW Posting Board
The user doesn't have to log into until they go to that section at which point
I use the following modules to authenticate them against MySQL and give them a
cookie only if they auth correctly (Careful, Apache::Cookie is broken as far as
I can tell with Apache::Session::MySQL hence the CGI)
use Apache;
use Apache::Request ();
use Apache::Constants qw(OK REDIRECT);
use Apache::Session::MySQL;
use CGI qw(:standard);
use DBI;
--
Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118
Science, Discovery, the Universe (UMCP)
Webmaster Webship Teacher
URL: http://www.sdu.umd.edu
EJPress.com
Database/PERL Programmer System Admin
URL : http://www.ejournalpress.com
Resume : http://www.p6m7g8.com/resume.txt
On Mon, 14 Jan 2002, Viljo Marrandi wrote:
Hello,
I'm on a mission ta make a web-site that uses cookies for user log-in
and log-out. First I'd like to know which one you suggest - Ticket
system from Eagle book or Apache::AuthTicket. I know that
Apache::AuthTicket is based on Eagle book's version, but it seems little
more advanced.
And now second problem. Has anyone modified one of these modules so,
that when user first enters the site he will get a cookie immediately
(with random generated ID) and can walk around there. And if he logs in
then the cookie gets modified accordingly (saying that user is logged
in).
Here's the situation. I must make a site for insurance company. User can
browse the site and see which offers he can get, if he wants to make a
deal only then he must log in. But all the data that is calculated must
be stored in dbase waiting for user to log in, so system can then, err,
bind this temporary data with current user. But of course user can log
in anytime he wants - even between different calculation steps.
Any ideas are welcome.
Rgds,
Viljo
Re: Ticket systems
Same and more questions ... And now second problem. Has anyone modified one of these modules so, that when user first enters the site he will get a cookie immediately (with random generated ID) and can walk around there. And if he logs in then the cookie gets modified accordingly (saying that user is logged in). I've got the same problem, as I'm using Apache::Session for generic cookie handling. Which is comfortable and on top I've got any session values stored in mySQL table. Then I wanted to build in my old style login,storing an loginflag to the actual session. When a secured page/file/component/location is requested and no loginflag is around he will be promted with a login page. So far so easy. Then I started to think ... a) Is the sessionkey of Apache::Session secure? Can it be tampered? Is some IP init? b) Could I use one of the existing Auth/Ticket modules working in the cookie of Apache::Session ... the same questions. BR Christian
Re: formmail spammers
Right, and point them to NMS for a replacement too. so, we've been having a spam problem lately due to formmail.pl. this thread prompted me to scan all our user directories and note people who had formmail.pl sitting around. I would have liked a link to send them to for the NMS replacement, but I saw two problems: 1. http://nms-cgi.sourceforge.net/ has only tarballs 2. the name of the script has a different capitalization in the tarball now, for us, this is a no-brainer. trying to get non-technical people (which the vast majority of our hosting customers are) to make the switch, though, will result in lots of headaches and support calls (which are expensive)... is anyone here involved in this project? what we really need is to be able to say: hey, just plop this file http://nms-cgi.sourceforge.net/formmail.pl in place of your old formmail.pl --Geoff
Re: formmail spammers
so, we've been having a spam problem lately due to formmail.pl. this thread prompted me to scan all our user directories and note people who had formmail.pl sitting around. We hardcoded the TO address in FormMail.pl and tell all our customers to do the same. Spammers trying to use the script will fail. Only the address in the TO field gets one messages.. Perhaps not the best solution around, but it will do until we fix something else. They don't get their spam out to the world. And we send their ISP a nice notification about what that user was trying to do. Complete with logfiles.. Once you're a know target they will come back.. Bye, B.
Re: formmail spammers
The latest FormMail.pl has been fixed. They can go to Matt's Archive and get the latest copy. Geoffrey Young writes: Right, and point them to NMS for a replacement too. so, we've been having a spam problem lately due to formmail.pl. this thread prompted me to scan all our user directories and note people who had formmail.pl sitting around. I would have liked a link to send them to for the NMS replacement, but I saw two problems: 1. http://nms-cgi.sourceforge.net/ has only tarballs 2. the name of the script has a different capitalization in the tarball now, for us, this is a no-brainer. trying to get non-technical people (which the vast majority of our hosting customers are) to make the switch, though, will result in lots of headaches and support calls (which are expensive)... is anyone here involved in this project? what we really need is to be able to say: hey, just plop this file http://nms-cgi.sourceforge.net/formmail.pl in place of your old formmail.pl --Geoff
Re: kylix: rad!
GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. consider struts, a popular java mvc framework. it defines simple interfaces for things like actions and forms. does struts (and mvc in general) work for non trivial websites? Struts is a framework, not a GUI builder. I'm all for frameworks, and we have stuff on CPAN that duplicates all the significant parts of Struts. a struts-oriented rad tool could easily scan WEB-INF dirs to find action and form classes and represent them in the gui. the main purpose of the tool would be to assemble and configure those classes in order to generate a struts-config.xml file. it could also incorporate ide functionality. Such a tool does exist for Struts, but all it does is generate/edit the config file. Too me, this doesn't seem very labor-saving (typing in a Swing app vs. typing in my text editor), but it might generate more interest among certain groups. Adding some mod_perl oriented stuff to whatever the leading Apache GUI is these days could be a good start. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. I'm not sure I want to try and draw in users who can't program at all. why do you think this tool would appeal to people who can't program at all? Because your post made it sound like you were talking about drag-and-drop wizard-driven GUI builders with pre-written components (which is what Kylix is trying to be, if I understand it correctly). There is a need for tools to generate instant database editing apps, and some projects to build those tools exist now. Beyond that, I think most users know enough Perl to write actual code in a good editor. There are already commercial Perl IDEs (aimed at CGI mostly) that have some code generation support and a set of pre-built components. Maybe looking at those would help to gauge developer demand for this kind of thing. - Perrin
Re: DECLINED unless 'text/html' but images never make it
How about trying: return DECLINED unless $r-is_initial_req; Image calls are not initial requests, they are sub requests. --Jon Robison R.Munden wrote: I've a script (controlled by a Location directive) that wraps a standard header and footer around an HTML page I've this at the top of my script: my $r = shift; return DECLINED unless ($r-content_type() eq 'text/html'); but any images that may be inline never make it to the browser (also, if I explicitly call the image in question it never makes it to the browser). Apache gives a 200 status code for these requests in the access log but Netscape 6.2 just sits there and IE returns a 'Cannot find server...' error. Any ideas, where to start looking, etc.? --rjm-- -- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.)
Re: RFC: Exception::Handler
I'm afraid I don't get it - isn't it what the finally functionality
in Error.pm (CPAN) does ?
try {
stuffThatMayThrow();
} finally {
releaseResources();
};
One reason for exceptions is to separate error handling code from the
normal control flow. This makes the normal control flow easier to
read. If releaseResources() is to be called whenever an exception
occurs, then it is advantageous to eliminate the extra syntax in the
class's methods and just have releaseResources() called whenever an
exception occurs and the object is on the stack.
Our exception handling class searches down the stack looking for
objects which implement handle_die(). It then calls
$object-handle_die($die), where $die is the exception instance. This
increases the cost and complexity of exception handling, while
decreasing the cost and complexity of normal control flow. It also
ensures that whenever the object is involved in an exception,
handle_die() is called giving it an opportunity to examine the
exception and clean up global state if necessary.
This eliminates a lot of explicit
try/catches.
Well, destructors are of some help too in that issue.
Not if the object is a class or if the object is still live, e.g. the
request context. We don't do a lot of instance creation/destruction
in our code. For example, our Task instances are created at start up.
They are executed repeatedly. Tasks decide whether to commit/rollback
on every execution, independent of the path through the Task class.
I'm agree with the need for try/catch. That's often the best way to
handle exceptions. There are cases where a global view is need,
however. Like Aspects, it ensures that you don't forget or have to
put in code where it is absolutely needed.
Rob
Re: RFC: Exception::Handler
On Mon, 14 Jan 2002, Rob Nagler wrote:
I'm afraid I don't get it - isn't it what the finally functionality
in Error.pm (CPAN) does ?
try {
stuffThatMayThrow();
} finally {
releaseResources();
};
One reason for exceptions is to separate error handling code from the
normal control flow. This makes the normal control flow easier to
read. If releaseResources() is to be called whenever an exception
occurs, then it is advantageous to eliminate the extra syntax in the
class's methods and just have releaseResources() called whenever an
exception occurs and the object is on the stack.
Our exception handling class searches down the stack looking for
objects which implement handle_die(). It then calls
$object-handle_die($die), where $die is the exception instance. This
increases the cost and complexity of exception handling, while
decreasing the cost and complexity of normal control flow. It also
ensures that whenever the object is involved in an exception,
handle_die() is called giving it an opportunity to examine the
exception and clean up global state if necessary.
Might be a fun thing to try out using the mysterious PROPOGATE method (try
it - implement a PROPOGATE method in your exception class, and watch for
when it gets called).
--
!-- Matt --
:-Get a smart net/:-
Re: DECLINED unless 'text/html' but images never make it
On Mon, 14 Jan 2002, Jon Robison wrote: How about trying: return DECLINED unless $r-is_initial_req; Image calls are not initial requests, they are sub requests. No. Requests for inline images are not subrequests. --Jon Robison R.Munden wrote: I've a script (controlled by a Location directive) that wraps a standard header and footer around an HTML page I've this at the top of my script: my $r = shift; return DECLINED unless ($r-content_type() eq 'text/html'); but any images that may be inline never make it to the browser (also, if I explicitly call the image in question it never makes it to the browser). Apache gives a 200 status code for these requests in the access log but Netscape 6.2 just sits there and IE returns a 'Cannot find server...' error. Igor Sysoev
Request Limiter
There was a module floating around a while back that did request limiting (aDOS preventional tool). I've searched the archives (unsuccessfully), and I was wondering if anyone knows what the heck I'm talking about. I thought it was on Matt Sergeant's web site, but for the life of me I can't remember what the url is. Can someone help? My next question would be, if I can't find the module, is what phase would I place a request limiter? Should it just go at the head of the PerlHandler chain, or earlier in the request phase? (I do have 'the book', but unfortunately, it's elsewhere right now). Thanks! -klm.
Re: Request Limiter
Ken Miller wrote: There was a module floating around a while back that did request limiting (a DOS preventional tool). I've searched the archives (unsuccessfully), and I was wondering if anyone knows what the heck I'm talking about. maybe you had Stonehenge::Throttle in mind? http://www.stonehenge.com/merlyn/LinuxMag/col17.html I thought it was on Matt Sergeant's web site, but for the life of me I can't remember what the url is. Can someone help? My next question would be, if I can't find the module, is what phase would I place a request limiter? Should it just go at the head of the PerlHandler chain, or earlier in the request phase? PerlHandlers are for delivering content. PerlAccessHandlers are for restricting access. If you're really feeling the load, you can use a PerlPostReadRequestHandler, which serves as kinda a general-purpose stage that occurs early on, as to nab the bad requests as early as possible. HTH --Geoff
problem with dup() in mod-perl?
Is anyone aware of a problem with dup-ing a fd to stdin?
Attached is a module I'm using to get the output of an exec-ed command.
When I call this module from a script it gives the right output.
When I call this from a Mason module, I get 0 0 0 (as if no input was read).
When I call this from the single threaded server (using -X), the request
hangs, and it seems to be taking input from my shell (the shell that
invoked 'httpd -X').
If I run strace on httpd, instead of a dup2(X, 0) call, I see a single
argument call dup(X); the dup to stdout is a dup2() call.
It seems that someone is intercepting the dup2(X, 0) call and treating it
as a single argument dup() call.
My platform:
Apache: 1.3.22
mod_perl: 1.26
Linux: Redhat 7.2/Intel
use strict;
use FileHandle;
package Test;
sub test {
my ($R, $W) = open_proc([ /usr/bin/wc ]);
print $W this is a test\n;
close($W);
my $buf;
while ($R) {
$buf .= $_;
}
close($R);
$buf;
}
sub open_proc {
my $args = shift;
my ($R1, $W1, $R2, $W2);
($R1, $W1) = FileHandle::pipe
or die unable to create pipes;
($R2, $W2) = FileHandle::pipe
or die unable to create pipes;
my $pid;
unless (defined($pid = fork)) {
die unable to fork: $!;
} elsif ($pid == 0) { # child
time;
open(STDIN, .fileno($R1))
or die unable to dup STDIN: $!;
time;
open(STDOUT, .fileno($W2))
or die unable to dup STDOUT: $!;
close($W1);
close($R2);
exec(@$args)
or die unable to exec .$args-[0].: $!;
}
($R2, $W1, $pid);
}
Re: Request Limiter
Geoffrey Young wrote: Ken Miller wrote: There was a module floating around a while back that did request limiting (a DOS preventional tool). I've searched the archives (unsuccessfully), and I was wondering if anyone knows what the heck I'm talking about. maybe you had Stonehenge::Throttle in mind? I wrote something a while back in response to users holding down the F5 key in IE and DOS'ing our website. It's called Apache::GateKeeper and is more polite than Throttle in that it serves cached content to the client instead of sending a 'come back later' message. It's configurable so after exceeding a threshold the client gets content from the shared memory cache, and if a second threshold is exceeded (ok this guy is getting REALLY irritating) then they get the 'come back later' message. They will only get cached content if they exceed x number of requests within y number of seconds. It works with Apache::Filter and there are two components - Apache::GateKeeper which is the first handler in the line of filters, and Apache::GateKeeper::Gate, which is the last in the line of filters and does the caching of content which will be served to the client if they are naughty. I would have liked to write this so that it just drops into an existing mod_perl app, but I couldn't find a way to grab an application's output before it got sent to the client for storage in the cache, so I set it up with Apache::Filter. Any suggestions on how to solve this? I've put the source on http://www.swiftcamel.com/gatekeeper.tgz It isn't packaged at all, and only includes the two modules I've grabbed straight out of our app - Apache::GateKeeper and Apache::GateKeeper::Gate. Currently this uses pnotes to pass POST data and messages between modules that are in the Apache::Filter chain, so it's really not the kind of thing you can drop into an app. Any ideas on how to write a version of this that one CAN simply drop into an existing application would be most welcome. ~mark.
Re: Request Limiter
It's configurable so after exceeding a threshold the client gets content from the shared memory cache, and if a second threshold is exceeded (ok this guy is getting REALLY irritating) then they get the 'come back later' message. They will only get cached content if they exceed x number of requests within y number of seconds. Nice idea. I usually prefer to just send an ACCESS DENIED if someone is behaving badly, but a cached page might be better for some situations. How do you determine individual users? IP can be a problem with large proxies. At eToys we used the session cookie if available (we could verify that it was not faked by using a message digest) and wold fall back to the IP if there was no cookie. Any ideas on how to write a version of this that one CAN simply drop into an existing application would be most welcome. It's hard to do that without making assumptions about the way to cache the content. Personally, I prefer to make this kind of thing an AccessHandler rather than using Apache::Filter, but your approach makes sense for you method of caching. - Perrin
RE: Request Limiter
If you're looking for limiting simultaneous requests to a URI resource (and not the entire server, which can be handled by MaxClients), you may be looking for mod_throttle_access. It can be found at http://modules.apache.org/search?id=232. Regards, Christian - Christian Gilmore Team Lead Web Infrastructure Tools IBM Software Group -Original Message- From: Ken Miller [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 12:14 PM To: [EMAIL PROTECTED] Subject: Request Limiter There was a module floating around a while back that did request limiting (a DOS preventional tool). I've searched the archives (unsuccessfully), and I was wondering if anyone knows what the heck I'm talking about. I thought it was on Matt Sergeant's web site, but for the life of me I can't remember what the url is. Can someone help? My next question would be, if I can't find the module, is what phase would I place a request limiter? Should it just go at the head of the PerlHandler chain, or earlier in the request phase? (I do have 'the book', but unfortunately, it's elsewhere right now). Thanks! -klm.
Re: my $var at file scope and __DATA__ sections under mod_perl
Each time, the warn is for 'blah' because the value 'test' is never retained in $var. Is this intended behaviour? No, that should create a closure that keeps the value of $var. Are you sure these requests are all going to the same instance? Weird, it's like the MIME::Types::DATA handle just mysteriously ran out of data halfway through reading from it. Does anybody have any idea what's going on here. No, but it doesn't obviously point to problems with closures and lexical scoping in my opinion. It looks more like you have a problem with that filehandle. - Perrin
[ANNOUNCE] Apache::SSI v2.17 uploaded
Hi, The uploaded file Apache-SSI-2.17.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-SSI-2.17.tar.gz size: 25819 bytes md5: b229a3a25a82935cad2da1af637714be Changes since 2.16: 2.17 Mon Jan 14 13:58:21 CST 2002 Added the Apache::FakeSSI class, which implements server-side includes in pure-perl so that its output can be filtered via Apache::Filter. Note that its !--#exec cgi=...-- isn't functional yet. Fixed a problem with the MANIFEST - file t/docs.check/16 was missing. -Ken
Re: Request Limiter
Perrin Harkins wrote: It's configurable so after exceeding a threshold the client gets content from the shared memory cache, and if a second threshold is exceeded (ok this guy is getting REALLY irritating) then they get the 'come back later' message. They will only get cached content if they exceed x number of requests within y number of seconds. Nice idea. I usually prefer to just send an ACCESS DENIED if someone is behaving badly, but a cached page might be better for some situations. How do you determine individual users? IP can be a problem with large proxies. At eToys we used the session cookie if available (we could verify that it was not faked by using a message digest) and wold fall back to the IP if there was no cookie. I'm also using cookies with a digest. There's also the option of using the IP instead which I added in as an afterthought since my site requires cookie support. But I have nighmares of large corporate proxies seeing the same page over and over. I wonder if this would be easier to implement as a drop-in with mod_perl2 since filters are supposed to be replacing handlers? And while I'm at it, is there a mod_perl 2 users (or testers) mailing list yet?
[OT] RE: formmail spammers
Last week there was a post to bugtraq about ways to exploit badly written scripts using cdonts.newmail, that exploited the fact that there was a SMTP conversation going on behind the scenes. This type of exploit can probably be used on a ton of other form mail type things, that use SMTP in the back end. http://www.nextgenss.com/papers/aspmail.pdf the quick summary is make sure you strip out \r's and \n's from fields that can't or shouldn't have them. The example uses a to address like this http://www.company.com/newsletter.asp?[EMAIL PROTECTED]%0D%0Adata%0D% 0ASubject:%20Spoofed!%0D%0A%0D%0AHi,%0D%0AThis%20is%20a%20spoofed%20email%0D %0A.%0D%0Aquit%0D%0A and just blindly set the to field in newmail. adam -Original Message- From: A.T.Z. [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 9:22 AM To: [EMAIL PROTECTED] Subject: Re: formmail spammers so, we've been having a spam problem lately due to formmail.pl. this thread prompted me to scan all our user directories and note people who had formmail.pl sitting around. We hardcoded the TO address in FormMail.pl and tell all our customers to do the same. Spammers trying to use the script will fail. Only the address in the TO field gets one messages.. Perhaps not the best solution around, but it will do until we fix something else. They don't get their spam out to the world. And we send their ISP a nice notification about what that user was trying to do. Complete with logfiles.. Once you're a know target they will come back.. Bye, B.
