Re: [challenge] new mod_perl site - [OT]

[Stas Bekman]

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/

Re: [challenge] new mod_perl site - [OT]

[Stas Bekman]

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: Cookie authentication

[Kyle Oppenheim]

> > 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: Cookie authentication

[David Young]

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. 
> 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

[Rob Nagler]

> 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: [DIGEST] mod_perl digest 2001/09/22

[Geoffrey Young]

> -Original Message-
> From: Robert Landrum [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 16, 2001 3:57 PM
> To: [EMAIL PROTECTED]
> Subject: 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

http://www.modperlcookbook.org/

RE: [DIGEST] mod_perl digest 2001/09/22

[Robert Landrum]

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: [DIGEST] mod_perl digest 2001/09/22

[Geoffrey Young]

> -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: [challenge] new mod_perl site - [OT]

[william ross]

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: no_cache()

[Rasoul Hajikhani]

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]

[allan]

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()

[David Wheeler]

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".



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: no_cache()

[Kyle Oppenheim]

$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: Apache-mod_perl

[Kyle Oppenheim]

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: Cookie authentication

[Kyle Oppenheim]

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: no_cache()

[Rob Bloodgood]

>#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: no_cache()

[Rasoul Hajikhani]

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: Doing Authorization using mod_perl from a programmers perspective

[Edward]

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

[Edward]

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 programmersperspective

[David Young]

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

[Stephen Adkins]

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
>> 
>
>

modperl 1.31 PDF pb

[pascal barbedor]

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

[Joe Breeden]

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

[Jon Robison]

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: Cookie authentication

[Joe Breeden]

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 perspec tive

[Geoffrey Young]

> 
> 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: Doing Authorization using mod_perl from a programmers perspective

[Geoffrey Young]

> 
> > 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 programmersperspective

[David Young]

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

[fliptop]

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.

Apache-mod_perl

[Manjrekar Pratiksha]

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)
**