SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264
|Anonymous | Login||2019-02-23 17:06 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001916||Endian Firewall||Proxy HTTP||public||2009-06-05 18:02||2010-03-03 15:34|
|Target Version||future||Fixed in Version|
|Summary||0001916: havp will always be used by every profile also when only one profile enables it|
|Description||It's not possible to selectively disable havp for some profiles. If one profile uses havp, all profiles use it.|
In order to have it as it is implemented currently in the gui (antivirus is possible to enable/disable per profile), dansguardian needs to understand that for one profile it must send the request to one parent and for another profile it needs to send it to another parent.
This is imho currently not possible.
As long as we don't have a dansguardian patch which allows this, we should change the gui, otherwise one thinks it is possible to enable/disable havp per profile.
|Tags||No tags attached.|
- dansguardian either allways or not uses havp (global dansguardian menu)
- use intergrated avengine of dansguardian (should be able to be defined per profile)
even when using avengine of dansguardian it is not possible to define if av engine should only be used for a specific dg profile. possible workaround: for a profile which should not use av make a whitelist rule for all.
sophos is not usable with dansguardian in an easy way (possible ways: icap server or DansGuardian Anti-Virus Plugin, but there is no evidence that this works with 2.10 dansguardian)
Conclussion: best solution for now is to keep havp and maybe patch dansguardian to give him possibility to have define proxy port per profile or make a global option for antivirus in combination with dansguardian.
i will check if it is worth to create a dansguardian patch which allows to configure a parent server per profile.
if the effort is to high, simon should move the checkbox outside the profiles in a global section.
a dansguardian patch would be possible, however it would break the NTLM auth plugin as far as I can say with that fast check i made.
The NTLM auth plugin needs a socket to the parent-proxy, which would not be possible to have in that moment, when we don't know yet to which profile the client belongs.
I don't exactly understand why the NTLM auth plugin exactly needs the parent proxy for authentication.
However, this probably may be not relevant for us, if we break the NTLM auth plugin, that *may* be acceptable for us for now.
In that case:
o is the option container holding all configuration from configuration files.
o.fg is an array holding all profile specific configurations.
- proxy_ip/port need to be read out from profile configuration file and stored
to the respective o.fg[xx] container. (happens in OptionContainer.cpp and
- ConnectionHandler.cpp:397 - connects to the parent proxy (o.proxy_ip,
o.proxy_port). This connection part need to be postponed after authentication
which happens in line 503.
In line 639 we know the filter-group and that's the best position to read out
proxy_ip and proxy_port from the filter-group.
proxy connection persistency should not break since one profile always uses
the same proxy.
- AuthPlugin::identify() in line 516 needs a working proxy connection
(proxysock), which will however used *only* by the NTLM authplugin.
In that stage we can't have a proxysock instance, since we don't know yet
which proxy to use. We could use the proxy of the default profile (?)
I'm just curious, is Endian 2.3 using the latest dansguardian release, 188.8.131.52? If not will 2.3.1 be using it?
|2009-06-05 18:02||peter-endian||New Issue|
|2009-06-05 18:02||peter-endian||Status||new => assigned|
|2009-06-05 18:02||peter-endian||Assigned To||=> simon-endian|
|2009-06-09 12:05||simon-endian||Note Added: 0002513|
|2009-06-09 12:10||simon-endian||Note Added: 0002514|
|2009-06-09 16:27||peter-endian||Note Added: 0002521|
|2009-06-09 16:29||peter-endian||Relationship added||child of 0001921|
|2009-06-11 16:10||peter-endian||Note Added: 0002586|
|2009-08-25 17:50||simon-endian||Assigned To||simon-endian => peter-endian|
|2009-10-27 13:33||peter-endian||Relationship deleted||child of 0001921|
|2009-10-27 14:07||peter-endian||Project||not released => Endian Firewall|
|2009-10-27 14:08||peter-endian||Target Version||=> 2.3.1|
|2009-11-27 15:12||simon-endian||Relationship added||related to 0002248|
|2009-12-13 14:31||wiseguytech||Note Added: 0003550|
|2010-03-03 15:34||ra-endian||Target Version||2.3.1 => future|
|Copyright © 2000 - 2012 MantisBT Group|