Cisco Unity Connection Cross-Origin Resource Sharing (CORS) for VMRest APIs CORS TOI for TAC Presenter Name: Aastha Wal Date: 20th March 2014
Agenda – Cisco CORS • Abbreviations • What is CORS? • Overview • Cisco Unity Connection APIs Supported • Under the Hood • Network Messaging • Configuration Using Cisco Unity Connection Administration • Administration Pages • Troubleshooting • Checklist for CORS configuration • CORS scenarios • Tools for Debugging • Additional Information
Abbreviations • API : Application Programming Interface • CORS : Cross Origin Resource Sharing • CUCA : Cisco Unity Connection Administration
CORS • Cross-Origin Resource Sharing is a standard mechanism that can be used by all browsers for implementing cross-domain requests. • It allows one site to access another site’s resources despite being under different domains. Unity Connection: • Earlier in Unity Connection Cross-domain requests was not supported due to Same Origin Policy. • CORS Support in VMRest in 10.5 release and onwards : - To support access of Unity Connection deployed in multi-domain environment. - It provides a way to allow list of “cross-domain” sites to interact with Unity Connection using VMRest APIs.
Which Cisco Unity Connection API’s currently support CORS • All VMRest APIs: • CUPI (Cisco Unity Connection Provisioning Interface) • CUMI (Cisco Unity Connection Messaging Interface) • CUTI (Cisco Unity Connection Telephony Interface) • CUNI (Cisco Unity Connection Notification Interface) • CUII (Cisco Unity Connection Imaging Interface)
Two requests are sent • OPTIONS • Rest Method (Head, Get, Put, Post, Delete) Foreign API Server Options – Do I have the access I’m requesting Rest Method
CORS “Add New” Wild cards allowed as a stand alone entry or only after the protocol
Checklist for CORS configuration • The browser must trust certificate of the original server(Cisco Unity Connection). • The domain should be configured in the Unity Connection. • Appropriate permissions should be given to the domain for initiating CORS request. There are two access types, Read-Only access (GET, HEAD) and Full-access (GET, HEAD, POST, PUT, DELETE). • Browser can cache the preflight request based on the response header “Access-Control-Max-Age” (in seconds). Default value is 1800 seconds / 30 mins. If changes to the configuration is made, browser cache should be cleared to reflect that change.
CORS GET request (failure scenario) No entry of domain on CORS page in CUCA
CORS GET request (success scenario) • Here the domain entry is present on CORS page in CUCA and Read-Only access is provided.
CORS PUT request (failure scenario) • Sending PUT request however in CUCA only Read-Only access is provided
CORS PUT request (success scenario) • Sending PUT request when in CUCA Full-access is provided
Collect Logs from RTMT Following log files can be collected from RTMT: • VMRest logs - diag_Tomcat_*.uc • Localhost logs – localhost_access_log.txt • Below are the steps to follow on RTMT • Login to RTMT • Goto: System Tools Trace Trace & Log Central • For diag_Tomcat logs: Click on Collect files select Connection TomcatApplication finish • For localhost logs: Click on collect files click next select Cisco Tomcat finish • Log files will be downloaded <Path will be mentioned on the screen>
Tools for Debugging CORS • Firefox add-on Firebug • Fiddler
Additional Information Browsers that support CORS • http://caniuse.com/cors Web Sites • http://www.w3.org/TR/cors • http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-origin-resource-sharing/ • https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS?redirectlocale=en-US&redirectslug=HTTP_access_control