Apache-mod_perl
Hello all, We are facing a problem while configuring perl-module in Apache webserver in the Solaris environment. The Server configuratin is as follows: OS : Solaris 2.7 SunOS 5.7 Sparc machine. Apache/1.3.20 (Unix) mod_fastcgi/2.2.10 mod_perl/1.26 We have installed a VSWAP1.1.6 which is a WAP test suite. The main file in this suite is index.eml 1. When we execute the index.eml file , we get the following error String found where operator expected wherever a subroutine was used. As suggested by a member of the mod_perl group, we inserted parenthesis for parameters of the subroutines. 2.This solved the error, but there was another error : Undefined subroutine Apache::ROOT::vswap1_2e1_2e6::index_2eeml::my_start called at /apps/vswap1.1.6/index.eml line 12. This could be solved by declaring package main in the perlmodule (.pm) file and referring all subroutines as (package name):: (subroutine) in the .eml file. refence url: http://perl.apache.org/dist/mod_perl_traps.html (Section: Perl Modules and Extensions ) 3.This gave another error Undefined subroutine Apache::ROOT::vswap1_2e1_2e6::index_2eeml::p However this error could not be solved by the method in point (2) Basically, we feel that there should not be any need to change the source code , the reason being we have installed the same test suite on a Linux machine. and it works fine there without any changes to the source code. Configuration of Linux: Apache/1.3.12 (Unix) (SuSE/Linux) ApacheJServ/1.1.2 mod_fastcgi/2.2.2 balanced_by_mod_backhand/1.0.8 DAV/1.0.0 mod_perl/1.24 PHP/3.0.16 Any quick help in this regard would be highly appreciated. regards, Pratiksha, ** The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony UK. If you have received this transmission in error, please contact our Helpdesk by email on [EMAIL PROTECTED] (05) **
Re: Doing Authorization using mod_perl from a programmers perspective
Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server.
Re: Doing Authorization using mod_perl from a programmersperspective
fliptop wrote: Joe Breeden wrote: How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. The session hijacker would not need to know the username and password. They would only need to sniff the cookie from the network, and then send it from a client identifying itself as the same User Agent. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response.
RE: Doing Authorization using mod_perl from a programmers perspective
my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response. the IP address is really a poor choice if I understand AOL and other large-scale proxies enough - they use a round-robin IP scheme where multiple requests _from the same user_ can appear as different IP addresses. the cool thing about the MD5 hashing scheme is that any would-be hacker needs to know the fields you are hashing in order to have a chance at creating a like hash. so, if you use stuff transmitted in the clear (like username, sessionid, some bogus piece of info not used, and MD5 hash) as well as other stuff obtainable from the transaction (like user-agent, protocol, method, accept header) and combine some random form of these (along with a server-side-only secret) the hash should be reasonably secure. this is kind of how digest authentication works (except there the algorithm is published, so you know the parameters involved). --Geoff
RE: Doing Authorization using mod_perl from a programmers perspec tive
the cool thing about the MD5 hashing scheme is that any would-be hacker needs to know the fields you are hashing in order to have a chance at creating a like hash. so, if you use stuff transmitted in the clear (like username, sessionid, some bogus piece of info not used, and MD5 hash) as well as other stuff obtainable from the transaction (like user-agent, protocol, method, accept header) and combine some random form of these (along with a server-side-only secret) the hash should be reasonably secure. this is kind of how digest authentication works (except there the algorithm is published, so you know the parameters involved). forgot to mention that you could also encrypt the entire thing in the cookie using something like Apache::Cookie::Encrypted, which uses blowfish or some other cypher. Apache::Cookie::Encrypted is pretty neat, except it doesn't do inheritance correctly so you can't subclass it, but it should prove as a good starting point for another effort... --Geoff
RE: Cookie authentication
Thanks David. It hadn't dawned on me to do the cookie storing/retrieving over SSL - sometimes I need to be hit over the head with a sledgehammer to see the obvious. Without some sort of secure mechanism to transport the cookie between the browser and app all the app can be assured of is that the cookie is valid. The app cannot be 100% certain that the cookie being sent is sent by the real owner of the cookie. Generally, I would say that most applications could use any of the proposals floated on the list yesterday and today and not worry about client sessions being hijacked. Of course, if a session is hijacked - how much damage is done is a question the developer needs to ask themselves. If the risks are acceptable then what is in the Eagle book and has been discussed is OK. If the risks are not acceptable then what David suggests is the way to go. And thanks to everyone who posted. --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: David Young [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:30 PM To: [EMAIL PROTECTED] Subject: Re: Cookie authentication I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT. The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. From: Perrin Harkins [EMAIL PROTECTED] Date: Thu, 15 Nov 2001 18:40:03 -0500 To: Joe Breeden [EMAIL PROTECTED], mod_perl List [EMAIL PROTECTED] Subject: Re: Cookie authentication Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
Re: Doing Authorization using mod_perl from a programmers perspective
fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
RE: Doing Authorization using mod_perl from a programmers perspective
The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
modperl 1.31 PDF pb
Hi I have problem trying to download the pdf version of the guide. several downloads always results in incorrect zip impossible to decompress. i already noticed this problem with former version of the guide. has anyone succesfully downloaded and uncompressed the pdf file ?* I am on win thanks pascal
RE: Doing Authorization using mod_perl from a programmers perspective
FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: Doing Authorization using mod_perl from a programmersperspective
Yes I remember reading about this some time ago. Of course I am short on specifics, but IIRC those were some sort of signature put in by ISPs who were bundling IE, and the id transmitted only configuration info but not specific user details. From: Stephen Adkins [EMAIL PROTECTED] Date: Fri, 16 Nov 2001 12:13:48 -0500 To: Joe Breeden [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: RE: Doing Authorization using mod_perl from a programmers perspective Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!)
Re: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: no_cache()
Ask Bjoern Hansen wrote: On Thu, 15 Nov 2001, Rasoul Hajikhani wrote: I am using $request_object-no_cache(1) with no success. Isn't it supported any more? Can some one shed some light on this for me... What do you mean with no success? What are you trying to do? -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com Well the cached document is returned rather than the new one. I know this because I make cosmetic changes to the document, reload it, and voila, still the old document. I have cleared the cache, set the cache size to 0, have even restarted the server at times just in case, but the result has been frantic. Sometimes the new document is shown on reloads, and at other times the old one is shown. -r
RE: no_cache()
#set the content type
$big_r-content_type('text/html');
$big_r-no_cache(1);
# some more code
return OK;
You *are* remembering to do
$r-send_http_header();
somewhere in (some more code), arent you?
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
RE: Cookie authentication
Amazon seems to include your session id in the URL in addition to a cookie. I assume they do this to personalize when cookies are turned off and to prevent proxy caches from caching personalized pages and serving them to the wrong end-user. If you happen to type in a URL, they can revive your session from the cookie. Pretty nifty trick. - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Young Sent: Thursday, November 15, 2001 4:30 PM To: [EMAIL PROTECTED] Subject: Re: Cookie authentication I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT. The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. From: Perrin Harkins [EMAIL PROTECTED] Date: Thu, 15 Nov 2001 18:40:03 -0500 To: Joe Breeden [EMAIL PROTECTED], mod_perl List [EMAIL PROTECTED] Subject: Re: Cookie authentication Excuse my question if it seems dumb I'm not 100% on NAT and proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to be user for the MAC. It also suggests to use the remote IP address as one of those fields. 3 Compute the MAC via a MD5 hash and store in the clients browser. 4 On subsequent visits recompute the MAC and verify it matches the original stored MAC. How is this reliable in a situation where many similarly configured computers are behind a NAT/Proxy and one of the users try to steal someone else's session by getting their cookie/session_id info? Don't use the IP address in the cookie, just generate a unique ID of your own. I suggest using mod_unique_id. - Perrin
RE: Apache-mod_perl
That error is simply saying that your subroutines, my_start and p, aren't defined in the current scope. The Apache::ROOT::vswap... is the package name that Apache::Registry (or similar module, sounds like maybe EmbPerl in your case) generated when it compiled your script. Check to make sure that you are exporting the sybols from your perl module (perldoc Exporter) and importing it in your script (perldoc -f use). - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Manjrekar Pratiksha Sent: Friday, November 16, 2001 1:05 AM To: '[EMAIL PROTECTED]' Subject: Apache-mod_perl Hello all, We are facing a problem while configuring perl-module in Apache webserver in the Solaris environment. The Server configuratin is as follows: OS : Solaris 2.7 SunOS 5.7 Sparc machine. Apache/1.3.20 (Unix) mod_fastcgi/2.2.10 mod_perl/1.26 We have installed a VSWAP1.1.6 which is a WAP test suite. The main file in this suite is index.eml 1. When we execute the index.eml file , we get the following error String found where operator expected wherever a subroutine was used. As suggested by a member of the mod_perl group, we inserted parenthesis for parameters of the subroutines. 2.This solved the error, but there was another error : Undefined subroutine Apache::ROOT::vswap1_2e1_2e6::index_2eeml::my_start called at /apps/vswap1.1.6/index.eml line 12. This could be solved by declaring package main in the perlmodule (.pm) file and referring all subroutines as (package name):: (subroutine) in the .eml file. refence url: http://perl.apache.org/dist/mod_perl_traps.html (Section: Perl Modules and Extensions ) 3.This gave another error Undefined subroutine Apache::ROOT::vswap1_2e1_2e6::index_2eeml::p However this error could not be solved by the method in point (2) Basically, we feel that there should not be any need to change the source code , the reason being we have installed the same test suite on a Linux machine. and it works fine there without any changes to the source code. Configuration of Linux: Apache/1.3.12 (Unix) (SuSE/Linux) ApacheJServ/1.1.2 mod_fastcgi/2.2.2 balanced_by_mod_backhand/1.0.8 DAV/1.0.0 mod_perl/1.24 PHP/3.0.16 Any quick help in this regard would be highly appreciated. regards, Pratiksha,
RE: no_cache()
$r-no_cache(1) adds the headers Pragma: no-cache and Cache-control: no-cache. So, you need to call no_cache before calling $r-send_http_header. You can verify that it works by looking at the headers returned by the server when you request your document. If your browser is caching the page w/o regard to these headers, then it's your browser, not mod_perl that's broken or misconfigured. - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:48 AM To: Ask Bjoern Hansen Cc: [EMAIL PROTECTED] Subject: Re: no_cache() Ask Bjoern Hansen wrote: On Thu, 15 Nov 2001, Rasoul Hajikhani wrote: I am using $request_object-no_cache(1) with no success. Isn't it supported any more? Can some one shed some light on this for me... What do you mean with no success? What are you trying to do? -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com Well the cached document is returned rather than the new one. I know this because I make cosmetic changes to the document, reload it, and voila, still the old document. I have cleared the cache, set the cache size to 0, have even restarted the server at times just in case, but the result has been frantic. Sometimes the new document is shown on reloads, and at other times the old one is shown. -r
RE: no_cache()
On Fri, 2001-11-16 at 11:59, Kyle Oppenheim wrote:
$r-no_cache(1) adds the headers Pragma: no-cache and Cache-control:
no-cache.
snip /
Huh, according to the mod_perl guide:
http://thingy.kcilink.com/modperlguide/correct_headers/2_1_3_Expires_and_Cache_Control.html
Those headers are not added by no_cache(1). But I see that, according to
the mod_perl Changes file, those headers were added to the behavior of
no_cache(1) in mod_perl 1.21_01. So perhaps the mod_perl guide should be
changed from its current documentation:
my $headers = $r-headers_out;
$headers-{'Pragma'} = $headers-{'Cache-control'} = 'no-cache';
$r-no_cache(1);
To simply:
$r-no_cache(1).
Stas?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: [challenge] new mod_perl site - [OT]
hello does anyone know what to do with this problem, which happens to me on Macintosh os X 10.1: [localhost:/Applications/modperl-site-new] aju% bin/build -vf # ### HTML DocSet: Home ### # +++ Reading cache from /Applications/modperl-site-new/bin/../src/cache.html.dat Byte order is not compatible at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_retrieve.al) line 311, at /Library/Perl/DocSet/Cache.pm line 37 [localhost:/Applications/modperl-site-new] aju% i have no problem with this: [localhost:/Applications/DocSet/example] aju% bin/build -vf thanks allan
Re: no_cache()
Rob Bloodgood wrote:
#set the content type
$big_r-content_type('text/html');
$big_r-no_cache(1);
# some more code
return OK;
You *are* remembering to do
$r-send_http_header();
somewhere in (some more code), arent you?
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Well then, that's what was missing :(...
thanks
-r
Re: [challenge] new mod_perl site - [OT]
same here, also on 10.1. I got past that one by forcing the got_storable sub to return 0, just out of curiosity, and was rewarded with complaints about the absence of Pod::POM::View::HTML. which is certainly absent. i imagine that a lot of the people you would most like to respond to your challenge are using OS X... will At 9:06 pm +0100 16/11/01, allan wrote: hello does anyone know what to do with this problem, which happens to me on Macintosh os X 10.1: [localhost:/Applications/modperl-site-new] aju% bin/build -vf # ### HTML DocSet: Home ### # +++ Reading cache from /Applications/modperl-site-new/bin/../src/cache.html.dat Byte order is not compatible at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_retrieve.al) line 311, at /Library/Perl/DocSet/Cache.pm line 37 [localhost:/Applications/modperl-site-new] aju% i have no problem with this: [localhost:/Applications/DocSet/example] aju% bin/build -vf thanks allan
RE: [DIGEST] mod_perl digest 2001/09/22
-Original Message- From: Adam Prime [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 3:29 PM To: 'Geoffrey Young' Subject: RE: [DIGEST] mod_perl digest 2001/09/22 have you stopped doing these things? CC'd to the list, in case anyone else is wondering... I took a brief haitus. as you may or may not know, I was working on a mod_perl book, and the time required for that was taking away from _everything_ else in my life. as somebody put it recently 'looks like you fell off the internet.' yup, and that was the least of it - no family time either, which gets you into deep trouble. well, the book is now complete and in the final stages of production - nothing left for us authors to do. I hope to start following the list again next week, which means I'll pull together a digest the week after... --Geoff this is the last one i've seen. I've been really busy lately and i had been hoping to cruise a digest to catch up. adam -Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 11:13 AM To: '[EMAIL PROTECTED]' Subject: [DIGEST] mod_perl digest 2001/09/22 __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com
RE: [DIGEST] mod_perl digest 2001/09/22
At 12:38 PM -0800 11/16/01, Geoffrey Young wrote: I took a brief haitus. as you may or may not know, I was working on a mod_perl book, and the time required for that was taking away from _everything_ else in my life. as somebody put it recently 'looks like you fell off the internet.' yup, and that was the least of it - no family time either, which gets you into deep trouble. What book? Or is it top secret? :) Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
RE: Cookie authentication
If you happen to type in a URL, they can revive your
session from the cookie. Pretty nifty trick.
This would seem to be a security hole to me. URLs appear in the logs
of the server as well as any proxy servers along the way. If the URL
contains reusuable auth info, anybody accessing any of the logs could
gain access to customer accounts.
to prevent proxy caches from caching personalized pages
and serving them to the wrong end-user.
If you want to ensure privacy, use:
$r-header_out('Cache-Control' = 'private');
If you want to turn off caching altogether, use:
$r-header_out(Pragma = 'no-cache');
Rob
Re: Cookie authentication
As I mentioned before, if you dissect what they do with cookies and when, you'll find they maintain two levels of session tracking, one for non-sensitive personalization uses and one for sensitive authentication uses. The URL session ID is likely only the former, and not exposing anything sensitive. I haven't spent a lot time seeing what they do when I disable cookies, but I do know that if I copy an URL (which contains my session ID) and send it to a friend, when that friend clicks on it, Amazon redirects to a new URL with a different session ID. From: Rob Nagler [EMAIL PROTECTED] Organization: bivio Software Artisans, Inc. http://www.bivio.net Date: Fri, 16 Nov 2001 15:22:02 -0700 To: [EMAIL PROTECTED] Subject: RE: Cookie authentication If you happen to type in a URL, they can revive your session from the cookie. Pretty nifty trick. This would seem to be a security hole to me. URLs appear in the logs of the server as well as any proxy servers along the way. If the URL contains reusuable auth info, anybody accessing any of the logs could gain access to customer accounts.
RE: Cookie authentication
If you happen to type in a URL, they can revive your session from the cookie. Pretty nifty trick. This would seem to be a security hole to me. URLs appear in the logs of the server as well as any proxy servers along the way. If the URL contains reusuable auth info, anybody accessing any of the logs could gain access to customer accounts. I disagree. The server logs are somewhat irrelevant because they should already be under access control, and they could contain anything including HTTP headers and content from post requests. As for proxies, they see the entire HTTP transaction anyway. If they aren't trusted, the data should be encrypted end-to-end with SSL. If the session-id is in the URL, an end-user cannot accidentally get a personalized page intended for somebody else. As you mentioned, you could prevent an intermediate cache from caching the page with a Cache-Control: private, but you then need to trust that the cache is HTTP/1.1 compliant. If anybody is afraid of using Amazon now, I believe David mentioned in a previous post that Amazon switches to SSL (and a new session id) whenever you deal with data they feel should be kept private. :-) - Kyle
Re: [challenge] new mod_perl site - [OT]
allan wrote:
hello
does anyone know what to do with this problem, which happens
to me on Macintosh os X 10.1:
I think the old cache files created on linux using Storable aren't
compat with osx. Try to delete them first:
% cd src
% find . -type f -name cache.html.dat -exec rm {} \;
Do you still have this problem?
[localhost:/Applications/modperl-site-new] aju% bin/build -vf
#
### HTML DocSet: Home ###
#
+++ Reading cache from /Applications/modperl-site-new/bin/../src/cache.html.dat
Byte order is not compatible at blib/lib/Storable.pm
(autosplit into blib/lib/auto/Storable/_retrieve.al) line 311,
at /Library/Perl/DocSet/Cache.pm line 37
[localhost:/Applications/modperl-site-new] aju%
i have no problem with this:
[localhost:/Applications/DocSet/example] aju% bin/build -vf
because this one doesn't have the old cache files. Sorry about that.
I'll release anothe src without the cache files.
_
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: [challenge] new mod_perl site - [OT]
william ross wrote: same here, also on 10.1. I got past that one by forcing the got_storable sub to return 0, just out of curiosity, and was rewarded with complaints about the absence of Pod::POM::View::HTML. which is certainly absent. This is a CPAN module. Please install it first. 'perl Makefile.PL' should have warned you about it. i imagine that a lot of the people you would most like to respond to your challenge are using OS X... _ 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/
