Thats why better alternatives like OAuth2 have been developed and adopted widely. But remember, that is not considered secure anymore nowadays. I will add a configuration switch to the 'Security' settings to allow Basic Auth authorization to the API from outside trusted networks to support such cases. It accept other Authorization methods as well which are allowed from outside the trusted network.īut I can see where external services 'only' offer HTTP (and therefor Basic Auth by putting username/pwd in the URL) calls to the Domoticz API and not provide alternative Authorization methods. The current 'issue' is the fact that the Domoticz API entrypoint only allows Basic Auth as authorization method when in a trusted network. The trusted network is exactly that, a 'trusted' network which provides valid Authorization. Either using the Login screen, providing a valid JWT Token, etc. You need Authorization to access Domoticz. Feels like, either nothing, or everything And from 'untrusted' locations where you want the auth to be there, it won't work, so the trusted list is a mandatory functionality, you can't work without it. The authorization is just to say who you are, but the password feature is completely irrelevant. It just tells Domoticz it can trust the provider Headers to find the real origin and process that origin accordingly.īut the authorization feature is currently a bit bogus right? You don't need authorization, everyone in the trusted list has full(!) access even without a username+password. So adding the IP address of the Proxy to the list does NOT open up access to everyone. If Domoticz can trust the Proxy, it will use the real origin IP address as provided by the Proxy headers. These headers tell Domoticz where the request really comes from (aa Domoticz only 'sees' the Proxy). When a (reverse) Proxy is used, the IP address of the Proxy has to be in the Trusted Network if Domoticz has to trust the Proxy Header information provided by the Proxy. Yes, Trusted network does not require (but still uses if provided) Authorization. When I add the reversed proxy to the trusted list it works of course, but then everyone can access domoticz Now it doesn't accept the authentication from outside the range. I use locative to send my location updates. But how can I make it work for IPs not in the trusted list? I need to be able to access it outside my network through a reversed proxy. Ok I didn't knew that is how it works, so trusted network will always be 'insecure' (no auth needed). Either I add the services that interact with http to the trusted list, but then authentication is practically disabled, or I don't add them to the list and authentication isn't possible at all This was not the case in the past and therefor a probable reason that in some setups now 'Access Denied' (401) are appearing.Īccess to Domoticz needs to be secure and controlled as more and more people are using it to control more and more things and not only from there privacy of there own homes but from everywhere.īut looks like it is even more insecure, as trusted networks can do whatever it wants without authentication. So when behind a Proxy, make sure that both the Proxy IP and the origin IP(s) are in the Trusted Network. Now it does and validates if the real host IP is secure or not. Before, Domoticz did not look at the actual origin IP of the request but merely at the IP address of the Proxy server. Anonymous and unsecured access to Domoticz is not possible anymore.Īlso using Basic auth (user/passwd in URL) to access the Domoticz API ( /json.htm) has been limited to access from the Trusted (previously called 'local') network.Įspecially setups where a Proxy is used in front off Domoticz, these changes are noticeable. Any idea, how to fix this problem without migrating to 6.5.In the latest Beta's security and Proxy handling have been improved and tightened. My vCenter version is 6.0.0U3f and my idea was to upgrade to version 6.5.0 (but actually not possible). I don't want to do this workaround after every restart. when services are starting I have to type password, which is stored in ( /etc/vmware-vpx/embedded_db.cfg) - postgres database passwordĪfter this process everything is fine and working, but I don't have an idea how to fix this problem permament. run command service-control -start -allĦ. then I kill all processes (with command kill), which are listed as output from command ps -ef | grep vpxd (connected with vmware-vpxd service)ĥ. here I can see, that there is something locked out - connected with vmware-vpxd service ( flock -on. ssh into vCenter appliance and run command: ps -ef | grep vpxdĢ. After 3 days of researching I have a workaround:ġ. After I reboot/restart my vCenter appliance (virtual machine) vmware-vpxd won't start and fail within initialization (everytime).
0 Comments
Leave a Reply. |