Betr.: [ic] proxy servers receiving 403 errors. WideOpen and TrustProxy

[J van Dijk 'BV Kunststoffenindustrie Attema']

Met vriendelijke groet,

Jan van Dijk
j.vandijk at attema.nl
B.V. Kunststoffenindustrie Attema
tel : 0183-650650 tst 674
fax: 0183-650751
www.attema.nl

>>> list_subscriber at yahoo.co.uk 8-9-04 1:05:01 >>>
>Recently a customer mentioned to us that they were unable to access
our site
>one day because they were getting an access denied page back from the
>webserver.

>On inspection of the web log I noticed there were quite a lot of
"status
>403: Forbidden" entries.  Closer inspection revealed that these errors
were
>only ever served up to cache/proxy servers.

>Here are some examples of hostnames showing 403 errors:

>cache-loh-ac06.proxy.aol.com
>glfd-cache-2.server.ntli.net
>manc-cache-2.server.ntli.net
>leed-cache-2.server.ntli.net
>lutn-cache-1.server.ntli.net
>lutn-cache-3.server.ntli.net
>cache1-popl.server.ntli.net
>bagu-cache-1.server.ntli.net

>From reading around I am guessing that I need to use one of WideOpen,
>TrustProxy or DomainTail in the catalog.cfg file to disable IP
qualification
>of user sessions?

>We use a real-time payment gateway (via an SSL encrypted page) and
PGP
>encrypted credit card information.  Does this mean that the best
approach
>would be to use "WideOpen Yes"?

>I still don't feel I fully understand the reason for the 403 errors,
or the
>best way to get over these proxy server problems:

>1) Does this mean that the session id is the *only* thing used to
identify
>session data?  Does this mean that anyone from any PC in the world
could
>provide the same session id as an argument to their URL and they would
then
>be able to see another customer's address details?  Or, would the fact
that
>the address details are only visible from a secure SSL page prevent
this
>anyway?

>2) Should I set SessionExpire to say 20 minutes?  Is this the length
of time
>after the *last* request that the session will expire.  i.e.  Will
the
>session only expire if the user *stops* browsing the website for a
period of
>more than 20 minutes?

>3) Is "WideOpen Yes" only necessary for compatibility with browsers
who have
>session cookies disabled?  i.e. Do proxy servers still cause a problem
for
>users who have session cookies enabled?

>4) Is there a better or different way to solve these 403 errors, or is
is
>"WideOpen Yes" the way to go?

>5) The site uses SSL pages for taking order & payment details, credit
card
>numbers are PGP encrypted, and a real-time payment gateway is used. 
In this
>situation, does "WideOpen Yes" still present any security risks that
we
>should be concerned about?  If so, is there anything else we can do
to
>mitigate against them?

>From all of the above, am I right to conclude that all customers of
ISPs who
>employ proxy servers will have intermittent problems accessing the
site
>unless "WideOpen Yes" is used?

>Any help or insight into the above would be greatly appreciated. 
Thanks.

We had some 403 access denied problems that where caused by an address
counter that wasn't reset.
Our workaround was to increase the RobotLimit to 500.

Jan