Re: [OT-ish] Session refresh philosophy
David Harris [EMAIL PROTECTED] on Feb 19, 2002: The encoded information is [...] split into reasonable length hidden fields. Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? Hans
Re: Streaming compression of output from mod_perl handler?
On Wed, 20 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote: I'm not sure that lynx can handle compressed response on the fly - it uses gzip in pipe. The best way to test it using netcat. Well, lynx didn't decompress it, it just output the gzip compressed content to stdout. As I didn't have netcat readily available on the machine, I instead put an strace on lynx, to be absolutely sure, that it didn't receive any output until the very end - and it didn't :-( I you like to test I can make patch for mod_deflate to flush Apache. But if major browsers can not handle compressed content on the fly it's not valuable. That would be an interesting patch, but with approx 450KB of uncompressed HTML, I would expect mod_deflate to receive compressible input, regardless if the content producer specifically flushes or not. But I might have misunderstood something. Regarding the browsers ability to handle compressed content on the fly, we probably won't know until I find a module that is able to produce such output. Sorry again. I've just checked sources and found that if mod_deflate received flush then it flushes both zlib and Apache. You can try to set autoflush in perl module with $|=1; or call $r-rflush; when you like to flush output. Igor Sysoev
Re: file globbing question
Cees Hek wrote: 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. another alternative is something like Apache::MIMEMapper... http://www.modperlcookbook.org/download/Apache-MIMEMapper-0.10.tar.gz which expands the AddHandler directive to make it a bit more mod_perl friendly. so, instead of using Files (which is perfectly legitimate) you can instead simply use AddHandler My::Module .qw and Apache will use My::Module::handler() for the content-generation phase. all the stuff Cees said it true, though - you still need to make sure your handler returns OK and follow the other handler rules. HTH --Geoff
Re: file globbing question
It occurred to me that using a scheme like this, it might be possible to help improve mod_perl's popularity... Or, at least, the popularity of Toolkits built under mod_perl... Using Files (or the Apache::MIMEMapper module), makes mod_perl a bit more ISP friendly, as it's a lot easier for users to add code to their files... Maybe using Embperl or something like that inside pages... Anyway, it's just a thought... Issac Geoffrey Young wrote: Cees Hek wrote: 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. another alternative is something like Apache::MIMEMapper... http://www.modperlcookbook.org/download/Apache-MIMEMapper-0.10.tar.gz which expands the AddHandler directive to make it a bit more mod_perl friendly. so, instead of using Files (which is perfectly legitimate) you can instead simply use AddHandler My::Module .qw and Apache will use My::Module::handler() for the content-generation phase. all the stuff Cees said it true, though - you still need to make sure your handler returns OK and follow the other handler rules. HTH --Geoff
Re: Streaming compression of output from mod_perl handler?
Sorry again. I've just checked sources and found that if mod_deflate received flush then it flushes both zlib and Apache. You can try to set autoflush in perl module with $|=1; or call $r-rflush; when you like to flush output. I just tried using $r-rflush in my handler and it works perfectly :-) The output gets rendered on the fly and it barely hurts the compression ratio. The 430 KB gets compressed to 26 KB instead of 24.5 KB :-) :-) But wouldn't it be nice to have some mod_deflate option where you could specify that mod_deflate should flush and send the currently compressed output every time it had received a certain amount of input or every time it had generated a certain amount of output. We are, for instance, using a template module to generate the output. We just give the template module a data structure and a template, and it then goes away and fills in the template, outputting HTML. This means that we don't have any easy way of calling flush at certain So we don't have any easy way of calling rflush once in a while. Of course we might just modify or substitute the template module, but it seems like a more automatic kind of streaming deflating (like described above) would be nice to have. Nicholas Oxhøj
Re: scripts running under Apache::Registry and tie()/untie()
[EMAIL PROTECTED] wrote:
Hi,
I'm very new to modperl and I've got a question regarding the usage of tie
() and untie().
I've written a perl-script for authenticating a user's IP-address
against a DBM-database which has stored a certain valid IP-range
for each user.
I put it into a directory where every .perl-file runs under
Apache::Registry.
Now I do a tie() once in the .perl-script. Do I have to untie() in the same
script
or is this not necessary because as I understood the perl-script keeps
living as long as the child-process who started it?!
If the dbm file access is read-only it's the best to tie it during
startup and then simply access it. If you need to read/write, read:
http://perl.apache.org/guide/dbm.html
e.g. startup.pl:
tie %Foo::Bar::dbm, NDBM_File, ...
and then in your code:
print $Foo::Bar::dbm{taz};
beware that if you use each(), keys(), values() on this dbm it won't be
shared anymore between the processes (though still work properly, but
more memory will be used). For more info read:
http://perl.apache.org/guide/performance.html#Sharing_Memory
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? I just installed and played with CGI::SecureState (using the example in the POD) and it is totally different than my module. When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain: Imagine a multi-step order process where the user works through pages A, B, C, and D, (which contain forms) then uses the back button to go back to page B, changes the form values, and submits the form. With CGI::SecureState, page C will receive the state information stored by page D (that was intended for use by page E, we presume), instead of the state originally stored by page B (that was intended for page C). This is because all the pages share the same key, and old versions of the state are overwritten by the new versions and no longer available. When the back button is hit, a newer version of state may be used where an older version was intended. With my module, page C always gets the state information stored for it by page B, since the state is stored in hidden form fields in page B. The browser is actually storing the state and will always submit that same state to page C. (I have mentioned that CGI::SecureState uses a non-versioning key a few times. A way to make CGI::SecureState tie the state information to the actual page would be to change the key whenever the state changed, thus creating a versioning key. The key could be a hash of the state itself. This potentially means that a huge number of versions of the state would have to be stored on disk. I think this method would only be helpful if the state is large and it's not acceptable to pass it back and forth between the client.) In addition, CGI::SecureState gets fuddled if the user opens a new window (something I do often) and then starts performing different operations in each window using the same state key! It has no way of knowing a new windows exists and generating a new key. If you just store a customer id, customer name, and other rarely changing information in the state, these concerns may not matter to you. If you break a long form or order process into multiple pages, gathering new information on each page and storing it in the state so that you can process the order at the end, then this is a likely problem. David
Re: [OT-ish] Session refresh philosophy
Hans Juergen von Lengerke writes: Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? That's what we do. There doesn't appear to be a restriction with POST. For while, we were encoding entire forms in URLs, but the limits got to us for really large forms. Rob
Re: Streaming compression of output from mod_perl handler?
On Wed, 20 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote: Sorry again. I've just checked sources and found that if mod_deflate received flush then it flushes both zlib and Apache. You can try to set autoflush in perl module with $|=1; or call $r-rflush; when you like to flush output. I just tried using $r-rflush in my handler and it works perfectly :-) The output gets rendered on the fly and it barely hurts the compression ratio. The 430 KB gets compressed to 26 KB instead of 24.5 KB :-) :-) What browsers did you test ? But wouldn't it be nice to have some mod_deflate option where you could specify that mod_deflate should flush and send the currently compressed output every time it had received a certain amount of input or every time it had generated a certain amount of output. It's complicates things. Besides Apache never flushes output on timeout or amount of content - it flushes only if you ask it. We are, for instance, using a template module to generate the output. We just give the template module a data structure and a template, and it then goes away and fills in the template, outputting HTML. This means that we don't have any easy way of calling flush at certain So we don't have any easy way of calling rflush once in a while. Of course we might just modify or substitute the template module, but it seems like a more automatic kind of streaming deflating (like described above) would be nice to have. You can set $|=1 as Eagle book says: This method [r-flush()] is also called automatically after each print() if the Perl global variable $| is nonzero. Igor Sysoev
Re: @INC Not exported in older perl's?
Elizabeth Barham wrote: Hi, I have been developing a web application using Apache and mod_perl. It consists of a single CGI perl script and many, many modules. The application was originally developed with perl 5.6. I moved it onto an i386 box running perl 5.005 and now there is a particular issue that I'm having trouble understanding. What happens is that an included module 'require's another module, but it's @INC is different than the one defined in the original, single CGI script. While one quick fix would be to simply add use lib '.' to the beginning of this particular module, I would rather diagnose the problem as I wonder why it's having this trouble. The error displayed using CGI.pm's carp is: Can't locate Time/DaysInMonth.pm in @INC (@INC contains: /usr/lib/perl5/5.005/i386-linux /usr/lib/perl5/5.005 /usr/local/lib/site_perl/i386-linux /usr/local/lib/site_perl /usr/lib/perl5 . /etc/apache/ /etc/apache/lib/perl) at ../lib/perl/Time/ParseDate.pm line 896 This does not include the directory included using use libs: use lib ../lib/perl; in the one cgi-bin file. The funny thing about this is that the module that is throwing the error's location happens to be ../lib/perl/Time/ParseDate.pm, which includes: require Time::DaysInMonth. Is there an easy solution to this? Am I missing something? Elizabeth, if I understand you correctly one of the modules adjusts @INC but other modules relying on this don't see the adjusted @INC. Changing the @INC value at server startup will solve this problem. For more info please read: http://perl.apache.org/guide/porting.html#_INC_and_mod_perl -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: [OT-ish] Session refresh philosophy
Hans Juergen von Lengerke [mailto:[EMAIL PROTECTED]] wrote: David Harris [EMAIL PROTECTED] on Feb 19, 2002: The encoded information is [...] split into reasonable length hidden fields. Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? The POST encoding dose not have a limit on data length. Heck, people use textarea tags with huge amounts of content all the time. However, I didn't feel comfortable assuming that the HTML parser used by the browser could easily parse a potentially 20kb attribute. Basically, I didn't want to make my production application a stress-test for my user's browsers. :-) It was easy to break the data up into multiple hidden fields, because Base64 encoding breaks the data into multiple lines by default. I simply encoded each line in one hidden field. I would *NOT* use my module with a GET form if you expect any size of data. I've seen the query string get truncated at some arbitrary size limit. David
Re: Segmentation fault
BeerBong wrote: We already did this! The question is - with 2 apache config, proxy-front-end apache logs every request, even if power apache daemon crushed with segfault, simple-proxy daemon logs request with URI and 502 status. We know time of segfault and can find 502 request in access logs with such time, and we can find out a request, wich causes seg fault. All right. It's working for 2 apache config. If we use simple 1 apache daemon, I think, we will have in logs segfault message only. Is there way to find out segfault request for simple configuration ? Provide a custom loghandler, which runs before the content generation phase or whichever phase the segfault happens at. Though you won't know the status, but there is nothing you can do after segfault. Or I can think of two steps handler, which let's say logs something before the potentially segfaulting handler and the status after the handler is run. So in case of segfaults the status will be missing. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT-ish] Session refresh philosophy
When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I'm well aware of the page-state vs. browser-state problem. I was recently bitten by it again when some consultants built a web app for my company that puts the search results in a session keyed on a cookie. As soon as the user opens two windows, it's absolute mayhem. - Perrin
Re: Streaming compression of output from mod_perl handler?
Can I find the Apache::Dynagzip handler anywhere - Google returns nothing... As far as I know the Apache::Dynagzip is not on CPAN yet. Currently, it's a property of OLT. Let me know if you are doing the Open Source Project and I will try to negotiate your needs with OLT. In case of commercial project you have to contact Tom Evans [EMAIL PROTECTED] yourself. Is your handler Apache::Filter Chain compatible? Not at the moment. But as it is only a content producer, isn't the only requirement, that I insert $r-filter_register() somewhere near the top of the handler, before returning any output? At least that is what I did, when I tried to test the Apache::Compress handler (which I didn't succeed in getting to work properly). Right, it's not a big deal when you have the source... Thanks, Slava
RE: [OT-ish] Session refresh philosophy
I can see how your approach adds functionality by performing as expected if the user uses the Back button or opens the app. in more than one browser window. The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? Wes Sheldahl David Harris [EMAIL PROTECTED] on 02/20/2002 09:50:11 AM To: Perrin Harkins [EMAIL PROTECTED], Drew Taylor [EMAIL PROTECTED], mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: RE: [OT-ish] Session refresh philosophy Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain:
Re: [OT-ish] Session refresh philosophy
The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. Both page types may have form input validation code on the server side, but in the first case this is just convenience for the user (warn early and don't say woops after 9 pages and 10 minutes of typing). The latter MUST have validation for security to hold (even if this means validating twice). This way, changing hidden fields gains an attacker nothing, since he will be blocked at the final submit anyway. Doing things this way also has other advantages e.g. interfacing: one can write automatisms with wget or LWP::UserAgent to trigger actions in the database without any further programming needed on the server side. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
[Fwd: ApacheCon news]
Please notice the address for responses: [EMAIL PROTECTED] Original Message Subject: ApacheCon news Date: Thu, 14 Feb 2002 17:22:37 -0500 From: Ken Coar [EMAIL PROTECTED] Organization: The Apache Software Foundation To: [EMAIL PROTECTED] Greetings! Please read BOTH of the following paragraphs.. I have good news! The Apache Software Foundation has completed the search for a conference management company for the ApacheCon shows, and we are getting back on track right now. More information will be forthcoming, but here's a quick point that may be of interest grin: Registration for the next ApacheCon will be well under US$1,000! We need some feedback from you: If we hold the next ApacheCon at the beginning of August 2002, in Las Vegas, Nevada, do you think you'll attend? We're asking because we're looking at the first full week of August, which would allow us to have ApacheCon right after the BlackHat and Def Con computer security conferences (URL:http://www.blackhat.com/ and URL:http://www.defcon.org/), also in Las Vegas around the same time. However, the USENIX Security conference in San Francisco is also happening then, the O'Reilly open-source convention is in San Diego in July, and LinuxWorld is in San Francisco in the middle of August. No matter where you look, the event schedule is crowded. So, with all those conferences so close together, would you come to ApacheCon? We don't want to pick a date and venue and then not have enough people able to attend! Please let us know by replying to [EMAIL PROTECTED]. Stay tuned, and thanks for your support and patience! -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT-ish] Session refresh philosophy
You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the hidden cleartext data from others on the client side. I guess that's a matter of how paranoid you think you need to be, and how confidential is the data you're storing. Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. Looks like it might worth be taking another look at this approach next time I start a new project. Wes [EMAIL PROTECTED] on 02/20/2002 11:48:28 AM Please respond to [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: Re: [OT-ish] Session refresh philosophy The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. Both page types may have form input validation code on the server side, but in the first case this is just convenience for the user (warn early and don't say woops after 9 pages and 10 minutes of typing). The latter MUST have validation for security to hold (even if this means validating twice). This way, changing hidden fields gains an attacker nothing, since he will be blocked at the final submit anyway. Doing things this way also has other advantages e.g. interfacing: one can write automatisms with wget or LWP::UserAgent to trigger actions in the database without any further programming needed on the server side. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
Re: [OT-ish] Session refresh philosophy
I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data structure. I prefer the simplicity of just worrying about a structure, and not having to worry about converting it to a string. That said, I like the approach that the two modules use. One just goes an extra step to guarantee data security. While looking for full-time employment, I've been doing some freelance work, which basically is small CGI apps. C:EF looks like it would make my life much easier by ensuring consistent state w/ small effort on my part, and take care of any security precautions as well. Combine that w/ CGI::Application (after I add TT2 support :-) ), and my life as a freelance CGI guy just got a whole lot easier. Thank you to everyone who contributed to this thread. I've gotten all kinds of neat ideas I'll use in future projects! Drew At 10:19 AM 2/20/2002 -0500, Perrin Harkins wrote: When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I'm well aware of the page-state vs. browser-state problem. I was recently bitten by it again when some consultants built a web app for my company that puts the search results in a session keyed on a cookie. As soon as the user opens two windows, it's absolute mayhem. - Perrin Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT-ish] Session refresh philosophy
[EMAIL PROTECTED] writes: Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. It is always good to validate the data even if it was encrypted. It is also generally a good idea not to give the user any secrets, even if they are encrypted. In other words, avoid trusting the user. [EMAIL PROTECTED] writes: No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. It is MVC. However, instead of thinking of pages, I like to think in terms of tasks. The same task that renders the form also validates and executes it. In the case of execution, the result is a redirect described by the site's state machine. A form in our world has four states: execute_empty (fill in defaults), execute_ok, execute_other (e.g., cancel or sub form), and execute_unwind (coming back from a sub form). All of these paths go through the same task. Rob
[DIGEST] mod_perl digest 2002/02/10
-- mod_perl digest February 10, 2002 - February 16, 2002 -- Recent happenings in the mod_perl world... Features o mod_perl status o available mod_perlers o mailing list highlights o links mod_perl status o mod_perl - stable: 1.26 (released July 11, 2001) [1] - development: 1.26_01-dev [2] o Apache - stable: 1.3.23 (released January 24, 2002) [3] - development: 1.3.24-dev [4] o mod_perl 2.0 - in development (cvs only) [?] o Apache 2.0 - beta: 2.0.32 (released February 14, 2002) [5] o Perl - stable: 5.6.1 (released April 9, 2001) [6] - development: 5.7.2 [7] available mod_perlers o Genius for hire [8] mailing list highlights o multiple authentication methods [9] o cookie as session store [10] o mod_perl, mod_gzip, incredible suckage [11] links o The Apache/Perl Integration Project [12] o mod_perl documentation [13] o mod_perl modules on CPAN [14] o mod_perl homepage [15] o mod_perl news and advocacy [16] o mod_perl list archives - modperl@ [17] [18] - dev@ [19] [20] - advocacy@ [21] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.apache.org/dist/httpd/ [6] http://www.cpan.org/src/stable.tar.gz [7] http://www.cpan.org/src/devel.tar.gz [8] http://mathforum.org/epigone/modperl/vehbrygrai [9] http://mathforum.org/epigone/modperl/soatwijum [10] http://mathforum.org/epigone/modperl/stangswaicho [11] http://mathforum.org/epigone/modperl/plexcloujam [12] http://perl.apache.org [13] http://perl.apache.org/#docs [14] http://www.cpan.org/modules/by-module/Apache/ [15] http://www.modperl.com [16] http://www.take23.org [17] http://mathforum.org/epigone/modperl/ [18] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2 [19] http://marc.theaimsgroup.com/?l=apache-modperl-devr=1w=2 [20] http://www.mail-archive.com/dev%40perl.apache.org/ [21] http://www.mail-archive.com/advocacy@perl.apache.org/
Re: [OT-ish] Session refresh philosophy
Rob Nagler wrote: [EMAIL PROTECTED] writes: Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. It is always good to validate the data even if it was encrypted. It is also generally a good idea not to give the user any secrets, even if they are encrypted. In other words, avoid trusting the user. [EMAIL PROTECTED] writes: No, this just means that input must be validated once again when the last «really, really sure ?» button is depressed. Conceptually, this divides the pages of your site into two categories (not unlike the view vs. controller distinction in Model-View-Controller paradigm for GUIs): those that just interact with the user and do the navigation, and those that actually have side effects such as writing data into your database, sending e-mails, placing orders etc. It is MVC. However, instead of thinking of pages, I like to think in terms of tasks. The same task that renders the form also validates and executes it. In the case of execution, the result is a redirect described by the site's state machine. A form in our world has four states: execute_empty (fill in defaults), execute_ok, execute_other (e.g., cancel or sub form), and execute_unwind (coming back from a sub form). All of these paths go through the same task. please take this as interested and not critical. i was viewing the source: http://petshop.bivio.biz/src?s=View.items and i noticed these lines: - snip ])-put( cellpadding = 2, cellspacing = 2, ), - snip - this looks like the presentation layer peeking through. the petshop site is obviously a demo, and therefore does not have the polished look of a professional site, which is very understandable. what i wonder is, could a professional web design team make a polished website without involving the programmers? what happens when a cell padding of 3 is more desirable for the design? it seems to me, that in all of the technologies i have looked at thus far, that attempt to separate the presentation layer from the model/view, the precision and flexibility needed to graphically communicate to the user is more difficult that the standard pagedesign approaches (dreamweaver and a little embperl or other embedded language thrown into the mix) . phrased another way, how does bivio or other mvc technology, let web artists design sites as beautiful as http://www.marthastewart.com or the even more beautiful http://www.genwax.com (cheap plug)? -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I looked at CGI::EncryptForm. It is used to store data on the client. The main difference between it and my module is that: (a) it encrypts the data, while I only prevent users from modifying the data, and (b) it stores the data in one field, while I store in multiple fields to make double sure that I don't hit any length restrictions. I'm well aware of the page-state vs. browser-state problem. I was recently bitten by it again when some consultants built a web app for my company that puts the search results in a session keyed on a cookie. As soon as the user opens two windows, it's absolute mayhem. I wasn't exactly what to call it and if people would recognize it by name, so I started writing a short description which just grew. :-) David
RE: [OT-ish] Session refresh philosophy
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: I can see how your approach adds functionality by performing as expected if the user uses the Back button or opens the app. in more than one browser window. The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web page info gets hijacked somehow. Does your module address this, or is this yet another tradeoff between security and functionality/convenience? My module addresses the first concern of an attacker changing the data in the hidden fields. On encoding, I hash together the encoded data and a secret to get a security hash. On decoding, I perform the same hashing and make sure it matches. Without the secret data no one can generate a security hash for modified data. My module does not address encryption. It would be trivial to add. It wasn't a concern with my application. By note of comparison, it looks like CGI::EncryptForm addresses both the encryption and non-user-modifiable concerns for the hidden data. David
RE: [OT-ish] Session refresh philosophy
Drew Taylor [mailto:[EMAIL PROTECTED]] wrote: I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data structure. I prefer the simplicity of just worrying about a structure, and not having to worry about converting it to a string. My module, FormContainer, takes arbitrary data structures like hash references too. You probably didn't see this because I used my own serializer module called FreezeThawLite instead of Storable. The lack of documentation of my module may have also been a problem. :-) I mentioned that a trivial rewrite to use Storable would be required when I attached the code. Simply replace FreezeThawLight::freeze with Storable::freeze and FreezeThawLight::thaw with Storable::thaw. :-) I agree with you that having to manually serialize session data to a string would be a real pain! That said, I like the approach that the two modules use. One just goes an extra step to guarantee data security. While looking for full-time employment, I've been doing some freelance work, which basically is small CGI apps. C:EF looks like it would make my life much easier by ensuring consistent state w/ small effort on my part, and take care of any security precautions as well. Combine that w/ CGI::Application (after I add TT2 support :-) ), and my life as a freelance CGI guy just got a whole lot easier. See my last message about the security comparisons. Thank you to everyone who contributed to this thread. I've gotten all kinds of neat ideas I'll use in future projects! Good stuff. David
Use of uninitialized value. with no line number in error log
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody know
what might cause this? Thanks.
-Tim
Re: Perl Section Bug?
On 13 Feb 2002, Salvador Ortiz Garcia wrote: Ok, I found it. Right now all Location, Directory and Files are afected by being upgraded at random to the Match versions. Can you please test the following patch for perl_config.c: You might be intersted to know that this patch also fixes strange problems I was having with Perl sections as well. Here is a link to the email where I reported the bug: http://www.geocrawler.com/archives/3/182/2001/2/200/5185227/ Doug looked at it for a while, but nothing obvious jumped out at him either so it just got listed as a ToDo :). Applying the patch you sent in this tread to mod_perl 1.26 makes the problem go away. Mike
Anyone for JavaScript question
I know this is off topic, but I thought someone could use a break... Given a page called xyz.html, I want to measure the amount of time a user spent on this screen (or page) along with other usability metrics. So I figured I'll use JavaScript since its running the entire time the page is up. Then I decided to use onload() and onunload() events to determine start and end of the session. The onload() part is easy. However when onunload() event happens, I need to execute a server side program and feed it the data that was collected. So I figured I setup a dumy form and invoke form.submit() onUnload. Would this work or is there a better method. I also thought about a redirect followed by another rediect to where the user wanted to go, but that gets too browser dependent and I don't like it when others hijak my browser. -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
method handlers and push_handlers / set_handlers
Is there a proper way to call a method handler using either push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the handler in
an anonymous sub is a workaround, but I was wondering if there was a better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
-Tim
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
Is there a proper way to call a method handler using either push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the handler in
an anonymous sub is a workaround, but I was wondering if there was a better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
-Tim
See
http://perl.apache.org/guide/config.html#Perl_Method_Handlers, the eagle
and cookbook books.
PERL_METHOD_HANDLERS=1 + $$ prototype for Apache::Test::handler
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Use of uninitialized value. with no line number in error log
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody know
what might cause this? Thanks.
Where did you set $SIG{__WARN__}? Try in startup.pl as early as possible.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Use of uninitialized value. with no line number in error log
Stas Bekman wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
Where did you set $SIG{__WARN__}? Try in startup.pl as early as possible.
It's set in startup.pl, which is basically a modified version of the example
from perl.apache.org/guide. It works beautifully for every other error I've
come across, which is why this one is so curious. As I mention in my earlier
follow-up to my own post, I eventually traced the problem to an incorrect
driver string in DBI-connect. However, that doesn't explain (to me anyway)
why I wasn't getting more detail in the error log. Perhaps I'll delve into
DBI.pm, unless someone can explain this to me beforehand.
-Tim
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
OK, in answer to my own question, after embedding debug statements all over
my code, I found the source of my problem: After finally moving this project
from Win2K to Debian, I neglected to update the driver string in
DBI-connect. How embarassing ... :-(
In any case, this still leaves the question: Why was there no line number or
back trace in the error log?
-Tim
Re: [Templates] problems with mod_perl example from Template Toolkit tutorial
Tim Noll wrote: As an alternative, I have used a PerlFixupHandler that detects a MIME type of text/html and for only those enables Mason leaving the rest alone. This lets autoindexing still work properly, as well as images and other content in the same directory. The same trick can work with Template. The code looks like this: I actually tried something like this after seeing it in one of your Web Techniques columns. Unfortunately, the content_type for anything in this Location is returning empty. As far as I can tell, because I'm using a Location directive but no Alias, Apache splits the URI between the directory and the file name, and thus looks at the directory when it tries to determine the filename and content_type, but puts the actual file name into path_info. That means that not only is there no corresponding file, but there's no extension on what Apache thinks is the file name, so it can't determine the content type. On the other hand, if I use an Alias directive and map that URI to the actual location of the template files, then Apache *can* determine the content_type. However, that eliminates the path_info that I was using as the file name in Template-process. Of course, I could always use filename instead of path_info, but that goes against Template's default rejection of absolute paths, which I assume is there for security reasons. Have I configured something wrong? Is this an issue only on Windows? I can now report that, having finally moved this project from Win2K to Debian, this problem has gone away. I haven't tested it rigorously enough to know whether it's really a Windows-only issue, but it's certainly gone now. Sorry to have bothered the Template list with this issue -- it's definitely a mod_perl thing. -Tim P.S. Hmmm ... this is my second reply to one of my own posts today ... maybe it's time for some sleep ...
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
OK, in answer to my own question, after embedding debug statements all over
my code, I found the source of my problem: After finally moving this project
from Win2K to Debian, I neglected to update the driver string in
DBI-connect. How embarassing ... :-(
In any case, this still leaves the question: Why was there no line number or
back trace in the error log?
I guess because any code can disable your setting locally or globally by
overriding $SIG{__WARN__} using local() or without it after you've
defined it. Or simply turning warnings off locally or again globally
(horrors).
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
When handlers misfire
I just ran into a problem with my PerlFixupHandler/PerlCleanupHandler based session manager (discussed earlier). It seems there's no guarantee that the cleanup handler will fire before the browser receives the response from the content handler. There's a niche case where a redirect will get to the browser and back to Apache before the cleanup handler has a chance to write the session to the database. If the redirected request needs that session data, there's a small chance it won't be there yet. Is there any way I can guarantee (short of hacking Apache::Registry) that my post-content code will run before the browser gets a response? From where I sit, the hack job looks like the best option right now. -- Milo Hyson CyberLife Labs, LLC
Re: When handlers misfire
Milo Hyson wrote: I just ran into a problem with my PerlFixupHandler/PerlCleanupHandler based session manager (discussed earlier). It seems there's no guarantee that the cleanup handler will fire before the browser receives the response from the content handler. um, yes there is. the content generation phase is guaranteed to be complete before per-request cleanups run _for a single request_. that's what the request cycle is all about. There's a niche case where a redirect will get to the browser and back to Apache before the cleanup handler has a chance to write the session to the database. that's something different :) due to some long running cleanups, I can see how a redirected response (which is a completely new request) could be initiated before cleanups are complete, since cleanups are run after the browser is released... If the redirected request needs that session data, there's a small chance it won't be there yet. have you seen this? I don't recall this ever coming up before (which doesn't mean it can't happen :) Is there any way I can guarantee (short of hacking Apache::Registry) that my post-content code will run before the browser gets a response? don't confuse the issue - a redirect involves _two_ requests to the browser, not one. From where I sit, the hack job looks like the best option right now. perhaps your post-content code in a PerlLogHandler instead of a PerlCleanupHandler might help if you are running into problems. the browser isn't released from the current connection until logging is complete, so there wouldn't be the chance that a redirect would be processed before the session is created. --Geoff
Re: [OT] MVC and web design
___cliff rayman___ writes: please take this as interested and not critical. i was viewing the source: http://petshop.bivio.biz/src?s=View.items Criticism welcome. I hope you don't mind the rant below. and i noticed these lines: - snip a ])-put( cellpadding = 2, cellspacing = 2, ), - snip - this looks like the presentation layer peeking through. The view components are all presentation. I didn't mention that the framework is actually MVCF, were the F stands for Facade. The server that runs http://petshop.bivio.biz also run http://www.bivio.biz The pet shop facade is: http://petshop.bivio.biz/src?s=Bivio::PetShop::Facade::PetShop and the www facade is something different, and not visible from the petshop facade. A facade in bOP controls the entire look and feel. In the case you pointed out, it might be a good idea to put the cellspacing and cellpadding in the facade, too. It was just laziness. the petshop site is obviously a demo, and therefore does not have the polished look of a professional site, which is very understandable. what i wonder is, could a professional web design team make a polished website without involving the programmers? Well, I guess it depends on what you mean by WebSite and programmers. I think of the pet shop as an application, not a WebSite. The same argument would apply for GUI desktop applications. Are you a programmer if you use JBuilder or PowerBuilder? I think so. Are you a programmer if you build a WebSite with ColdFusion or PHP?Again, I think so. If you are a programmer, then you need to know how to program. I don't see anything hard about programming Perl in a constrained environment if you are a website designer/programmer. Structure is important in most WebSites, and all web-delivered applications imiho. If you just want to do layout, there are many tools which are much better than an HTML editor, e.g., Photoshop. Once the layout is complete, you give it to coders who encode it in whatever language is best for the application delivery mechanism. what happens when a cell padding of 3 is more desirable for the design? The designer modifies the source in CVS, tests it, and checks it in. it seems to me, that in all of the technologies i have looked at thus far, that attempt to separate the presentation layer from the model/view, the precision and flexibility needed to graphically communicate to the user is more difficult that the standard pagedesign approaches (dreamweaver and a little embperl or other embedded language thrown into the mix) . phrased another way, how does bivio or other mvc technology, let web artists design sites as beautiful as http://www.marthastewart.com or the even more beautiful http://www.genwax.com (cheap plug)? rant Ah, that is the question. The answer is beauty is in the eye of the user. I work with a lot of sites at the technical level, and I'm continually may amazed at the low quality of the sites from a user perspective. Let's take Martha Stewart (please ;-) and visit your account. For your info, the link is: http://www.marthastewart.com/page.jhtml;jsessionid=4HVBOQCWGUVEHWCKUUXCIIWYJKSS0JO0?type=page-catid=cat688 This is a good example of the business logic creeping in to the UI. What do I care if Martha programs in Java. What happens to her users' bookmarks if she switches to C#, or heaven forbid Perl? In bOP, you can have any link you want associated with a task on a per Facade basis. In fact you can have multiple links pointing to the same task. Look at the links in http://www.bivio.com/demo and see if they make sense to you. We have some pretty advanced users, who take our links and embed them in custom home pages in their files area (which is browsable unlike most groupware sites). We can maintain backward compatibility forever. Now when I come to the page on Martha's site which asks me to login it's very pretty and weighs in at 45KB without counting the rose (32KB). I can't login here, because there are no form fields. The rose is very pretty though (did I say that already?). Many of our users still connect to us with AOL at 26kbps with 60mhz/32MB boxes. They definitely appreciate the fact that most or pages are under 20KB. Only because our pages are programmed that way. In summary, I buy into the minimalist approach of Nielsen. Visit http://useit.com for more info. Usability is designed, and it takes a lot of time to design and test it. The actual coding part is minuscule in comparison. /rant Rob
Help with tuning mod_perl under freebsd
I'm having some trouble tuning startup.pl under FreeBSD, under linux, I can easiler figure out how well my startup.pl works by looking at the value RSS and SHARE in Top, but in freebsd the value SHARE is missing and I'm unable to find any alternative index that indicate how the startup.pl benefit each apache children's memory usage. So, anyone can give me a hand on this? Many thanks. Tor.
cvs commit: modperl-2.0/lib/ModPerl TypeMap.pm
dougm 02/02/20 17:40:03
Modified:lib/ModPerl TypeMap.pm
Log:
loosen aTHX check; might be register PerlInterpreter
Revision ChangesPath
1.13 +1 -1 modperl-2.0/lib/ModPerl/TypeMap.pm
Index: TypeMap.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/TypeMap.pm,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- TypeMap.pm7 Nov 2001 03:14:54 - 1.12
+++ TypeMap.pm21 Feb 2002 01:40:03 - 1.13
@@ -203,7 +203,7 @@
return unless $first;
-if ($first-{type} =~ /^PerlInterpreter/) {
+if ($first-{type} =~ /PerlInterpreter/) {
shift @{ $func-{args} };
$func-{thx} = 1;
}
