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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
#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
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
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
$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
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
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
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
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
-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
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
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
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
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
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
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.
29 matches
Mail list logo
