CacheGuard Help

Hello

I'm happy to hear that
I'll add the improvement you suggested to our todo list and may develop it one day. Thanks for the idea.

Best Regards,

Hi Miguel Again I did a mistake and wasn't clear enough; sorry for the inconvenience. Actually the right port to use depends on your configuration. Use the following command to display the Web auditing port: port waudit By default it should be 8091. I rectified my initial post to reflect this change...

Hello Miguel

You are right as the correct command that activates the access logging is:
Could you connect to the port 9090?

I rectified my previous post by replacing "log web on" by "log type web on".

Best Regards,
David

Dear Jose To answer you questions: - You can use SSH (putty or any other SSH client) to remotely access to the CG CLI (Command Line Interface). But in order to have access via SSH you need to enable the ssh administration option using the following commands: admin ssh on apply force - You will also ...

Dear RMansell You have not been posting your replies since a long time. If you think that CacheGuard doesn't meet your particular needs we can close this topic. What do you think? I also want to further clarify for our readers that with CacheGuard in its present version (NG 1.1.2): - Backend servers...

Hi Any modification that will make the forwarding proxy restart reinitialize the TTL. For instance you can do the following: mode compress on apply Do your tests. mode compress off apply And so on... Also you may need to restart your Web browser if you need to retest the authentication phase. Best R...

Dear Miguel

The behaviour you described is normal. With CacheGuard, the TTL (Time To Live) for an authenticated session is 2 hours. The TTL for and LDAP filter is also 2 hours.

Best Regards,

Hi Miguel

Yes, exactly.

Best Regards,

Dear Miguel All those features are normal: 1- When a URL is blocked by CG the end-user is redirected to a blocking page. But when the blocked URL uses HTTPS, the redirection is not possible because SSL/TLS simply doesn't allow that redirection so you get an error in your browser instead of the block...

Hi Miguel I'm happy that you got closer to the right solution. In response to your initial post the documentation says: An LDAP request filter allows you to define guarding policies where the access for end-users is granted if that LDAP request returns a value. This type of filter is only applicable...