JSONP is always a popular way to use the open policy of SCRIPT HTML elements to implement the cross-domain access by a lot of developers. However, most of their knowledge blogs are just the segments of one of the integrated solutions. In this article, we will introduce a whole integrated solution to implement the cross-domain access to WCF Service in SharePoint Site Collection by HTTPS protocol. There are four main parts for the solution: the WCF service cross-domain SSL configuration, the WCF service interface JSONP implementation, the WCF service deployment and the JSONP Ajax call implementation.
1. Introduction
In general, browsers will forbid one we page of one web site to get the resource on another domain server. We called this way as same-origin policy. However, anything has an exception. The <script>, <img> and <iframe> html element can access to the resources on the other domain server. This way used to be called as open policy. For an example, we often saw the following html segment in the html file: <script src=”https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js”> </script>. This is a sample of open policy. It looks like very easy. JSONP is born in that way. It usually loads a script file as the resources on the other domain server. The script file used to have a similar content with JavaScript method which has been predefined with a known name and several parameters. The parameters will be the JSON format data you want to get in purpose. When the JavaScript code is executed, you will get the data in the method you predefined. However, it will be not easy, if you try to access to the WCF service to get the resource you want. You will perhaps get an unauthorized error with the code 401. Because you find it that the WCF service need windows authentication. It is also caused by the expired SSL certification. Besides, you may get into the trouble like the following error: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. So terrible that way! Don’t be worried. We have find out a way to solve all the above problems. We will introduce a way to solve the windows authentication. We will also figure out a way to solve the expired SSL certification issue. The cross-domain issue is also easy to come over. Please follow the below steps to finish your solution.
2. Authentication & Credential
When we populate a cross-domain SSL request to WCF service, we should pay more attention to three aspects: Cross Domain Enabled, Windows Authentication Enable and SSL Credential Available. Let us leave the Cross Domain topic alone. We will discuss it next section. Just focus on the Authentication and Credentials. For the authentication, it used to be broken into two cases: Anonymity and Windows Authentication. At the first step, we need add something in configuration to support one special authentication. As the diagram 1-1 shows, this is a sample for Windows Authentication.
Figure 1-1 Windows Authentication Configuration
For Anonymity, the clientCredentialType attribute of transport node should be ‘None’. What’s more, we also need update the IIS Site or Site Application settings for authentication to support the Anonymity and Windows Authentication as the diagram 1-2 and 1-3 shows.
Figure 1-2 IIS Site Settings
Figure 1-3 IIS Site Authentication Settings
We will talk more detail about IIS settings in the deployment paragraph. After configuration and IIS settings, the authentication should be ready. However, your program may still be out of work. Because you will find it that your browser do not trust the visited site. One way to trust the visited site is to add the SSL credential for browser. If have not one, we need add one. Another way to add the site to the exception of browser. The program solution is to create a site which we can have an anonymous access to. When we open my site, we first to have check and open the site page which help to load SSL credential for bowser in new windows.
3. Cross Domain Enable
After the settings for authentication, we need enable cross domain for WCF service. There are some blogs to suggest you of ‘crossDomainScriptAccessEnabled’ settings and even ‘[JavascriptCallbackBehavior]’ attribute adding on WCF Service Class. Unfortunately it will bring another problem. [JavascriptCallbackBehavior] is not supported by WCF service with Windows Authentication. If do that, you will get an unsupported exception error. One way to enable cross domain in WCF service is to add the following CORS settings in the <system.webServer> node of WCF configuration file as the diagram 2-1 shows.
Figure 2-1 CORS cross domain settings in WCF
If you want to the limit the visitor for cross-domain request, you can set the value of ‘Access-Control-Allow-Origin’. For an example, you only allow the site ‘http://www.a.com’ to have a cross-domain visit. You can set the value of ‘Access-Control-Allow-Origin’ to ‘http://www.a.com’’. The asterisk signal stands for no limitation. Other CORS settings are optional. The ‘Access-Control-Allow-Headers’ is used to control the http header information. The ‘Access-Control-Allow-Methods’ used to set the way of request. In common sense, it is set to ‘POST,GET,OPTIONS’. The ‘Access-Control-Max-Age’ controls the time out of each cross-domain request.
4. Web HTTP REST Service Configuration
At this section, we will state how to configure the WCF application to support Web HTTP REST request. Let’s focus on the HTTPS REST service configuration in this paragraph. It will be similar to the configuration for HTTP.
- Set the protocol schema for HTTPS.
You need add the below XML snippet in the <system.serviceModel> node of configuration file.
<protocolMapping>
<add binding=”basicHttpsBinding” scheme=”https”/>
</protocolMapping>
- Set the Web HTTP end point behavior.
Add a web http behavior in the <endpointBehaviors> of <behaviors> child node of the <system.serviceModel> node in the configuration file.
<endpointBehaviors>
<behavior name=”web”>
<webHttp/>
</behavior>
</endpointBehaviors>
- Set the Service Behavior.
Except of the end point behavior, we need also configure the service behavior by adding <behavior> settings in the <serviceBehaviors> child node of the <behaviors> node.
<serviceBehaviors>
<behavior name=”ServiceBehavior”>
<serviceMetadata httpsGetEnabled=“true” httpGetEnabled=”false”/>
<serviceDebug includeExceptionDetailInFaults=”false”/>
</behavior>
</serviceBehaviors>
- Set the Web HTTP binding.
WCF binding is used to control security settings, request process time out, request content encoding and so on. Here we will just focus the security settings as the Authentication and Credential section mentioned. We need add the below XML snippet in the <system.serviceModel> node.
<bindings>
<webHttpBinding>
<binding name=”wsHttp1″>
<security mode=”Transport”>
<transport clientCredentialType=”Windows”/>
</security>
</binndig>
</webHttpBinding>
</bindings>
- Enable ASPNET compatibility.
Enable the ‘aspNetCompatibilityEnabled’ attribute of ‘serviceHostingEnvironment’.
<serviceHostingEnvironment aspNetCompatibilityEnabled=”true” multipleSiteBindingsEnabled=”true”/>
