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

J van Dijk 'BV Kunststoffenindustrie Attema' j.vandijk at
Wed Sep 8 03:10:48 EDT 2004

Met vriendelijke groet,

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

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

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

>Here are some examples of hostnames showing 403 errors:


>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
>of user sessions?

>We use a real-time payment gateway (via an SSL encrypted page) and
>encrypted credit card information.  Does this mean that the best
>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
>session data?  Does this mean that anyone from any PC in the world
>provide the same session id as an argument to their URL and they would
>be able to see another customer's address details?  Or, would the fact
>the address details are only visible from a secure SSL page prevent

>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
>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
>users who have session cookies enabled?

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

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

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

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.


More information about the interchange-users mailing list