> Hello, > According to the wiki at: > http://wiki.sipfoundry.org/display/sipXecs/Call+Control+Web+Service > "If you are issuing the curl command from a trusted host ( i.e. one where > sipx proxy is running) please use only HTTPS (no authentication is > required)." > > However, If I use the HTTPS port 6666 I get returned data that it requires > authentication. Is a "trusted host" only another cluster member, or should > it not require auth from the local host as well? > > if I issue a POST request on port 6667 unauthenticated, the call is > placed, If I use the HTTPS port 6666 I get returned data that it requires > authentication. This happens with requests initiated by remote hosts as > well. > > Is this also expected behavior, or does the wiki have reversed data? > Is this 4.4 or 4.6? We have done various changes in 4.6 regarding how communication inside cluster is done and how should we communicate from outside cluster The wiki document wasn't updated from some time, and does not reflect changes that we done in 4.6. Trusted host is a concept used only in 4.4. localhost and primary were trusted host, meaning that if the call was done from these hosts, authentication layer was bypassed
Here is how it works in 4.4: -port 6667 is a HTTP port and uses digest authentication -port 6666 is a HTTPS port and uses basic authentication In 4.6: -port 6667 is HTTP port and meant to be used only internal (inside cluster), no authentication, should not be visible outside cluster (we have different ways to encrypt data inside cluster and there is configurable in UI to encrypt or not data inside cluster) -port 6666 is HTTP (we removed SSL Listener) and uses digest authentication In 4.6 only apache server that we have in front does SSL and any SSL call should be proxyed through apache (so there are no SSL listener inside components anymore) - look into: http://track.sipfoundry.org/browse/XX-10098 For callcontroller we did not yet have a reverse proxy in apache to route SSL calls (will address it post 4.6) but we do have a REST api in sipxconfig that is recommended to be used (port 443, SSL, basic authentication, LDAP authentication) instead of directly connecting to port 6666 /my/redirect/<callcontroller relative uri> example: https://192.168.1.102/sipxconfig/rest/my/redirect/callcontroller/200/201(places a call from 200 to 201) We decided to route everything throuth sipXconfig authentication layer because this is the most complex and we can perform LDAP authentication too. We did not spend time to create the reverse proxy mechanism in apache to callcontroller and ivr, because we would have missed the LDAP authentication. Right now apache proxies calls only to sipXconfig and therefore we use sipXconfig authentication layer for callcontroller rest apis and ivr rest apis I think that the solution here would be to create a dedicated authentication component that will be independent, outside sipXconfig, and apache will proxy to it (will tackle this task post 4.6) Mircea > > Thanks, > > -- > Alan Worstell > A1 Networks - Systems Administrator > VTSP, dCAA, LPIC-1, Linux+, CLA, DCTS(707)570-2021 x204 > For support issues please email supp...@a-1networks.com or call 707-703-1050 > > > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
