Connection authentication by the Web-server

Top  Previous  Next

JSON-object

 

Please refer to the previous section to configure the 'connect' REST API method only. Suppose you configured the app to use this URL: http://localhost/defaultApp.

This means WCS will query the local Web-server, for instance, Apache to receive a JSON response.

 

Since we are using only the 'connect' method, our Web-server should correctly process queries like this one: http://localhost/defaultApp/connect.

 

In this case, all your Web-server code should do is to return a JSON object:

 

{

 "sipRegisterRequired" : true,

 "sipLogin" : "mySipLogin",

 "sipAuthenticationName" : "mysipAuthenticationName",

 "sipDomain" : "mySipDomain",

 "sipOutboundProxy" : "sipOutboundProxy",

 "sipPassword" : "mySipPassword",

 "sipPort" : "mySipPort"

}

 

The object contains SIP-data that will be used for SIP registration on the SIP server. You don't need to send data from the client as it is REST API that is in charge for that.

 

Web-client code

 

//The code does not contain any SIP parameters
function connect(){
    f.connect({urlServer:'ws://192.168.1.5:8080',appKey:'defaultApp'});
}

 

Web-server code

 

Let's show how the REST API works using Apache as an example.

 

1. Add JSON support. This is required to make the server respond with Content-Type: application/json header when a .json URL is queried. Otherwise WCS will not be able to parse JSON-response of the server. To do this, add the following line to /etc/httpd.conf:

 

AddType application/json .json

 

2. Configure mod rewrite to add URL corresponding to methods of the REST API. This requires us to enable .htaccess in /etc/httpd.conf:

 

<Directory>
   Options FollowSymLinks
   AllowOverride All
</Directory>

 

3. On the next step we configure URL rewrites in the folder of the website. The .htaccess file:

 

Options +FollowSymLinks

RewriteEngine On

RewriteRule ^defaultApp/connect /connect.json [QSA,L]

RewriteRule ^defaultApp/ConnectionStatusEvent /ConnectionStatusEvent.json [QSA,L]

RewriteRule ^defaultApp/RegistrationStatusEvent /RegistrationStatusEvent.json [QSA,L]

 

Here we have three rules telling the server to return .json files when the corresponding URL is queried.

 

For example:

 

http://flashphoner.com/defaultApp/connect >>> http://flashphoner.com/connect.json

http://flashphoner.com/defaultApp/ConnectionStatusEvent >>> http://flashphoner.com/ConnectionStatusEvent.json

http://flashphoner.com/defaultApp/RegistrationStatusEvent >>> http://flashphoner.com/RegistrationStatusEvent.json

 

4. Contents of .json files

 

connect.json contains information about the SIP account

 

Example:

 

{
    "sipRegisterRequired" : true,
    "sipLogin" : "WCS1",
    "sipAuthenticationName" : "WCS1",
    "sipDomain" : "sip.org",
    "sipOutboundProxy" : "sip.org",
    "sipPassword" : "12345",
    "sipPort" : 5060
}

 

 

ConnectionStatusEvent.json is an empty JSON-object

 

{}

 

RegistrationStatusEvent.json is an empty JSON-object

 

{}

 

Page

 

<!DOCTYPE html>
<html>
<head>
    <title>Phone min</title>
    <!-- JQuery -->
    <script type="text/javascript" src="../../dependencies/jquery/jquery.js"></script>
    <script type="text/javascript" src="../../dependencies/jquery/jquery-ui.js"></script>
    <script type="text/javascript" src="../../dependencies/jquery/jquery.websocket.js"></script>
    <script type="text/javascript" src="../../dependencies/jquery/jquery.json.js"></script>
    <!-- ****** -->
 
    <!-- WCS JavaScript API -->
    <script type="text/javascript" src="../../Flashphoner.js"></script>
 
    <script type="text/javascript" src="../../dependencies/swf/swfobject.js"></script>
 
    <!-- Minimum script for calls -->
    <script type="text/javascript" src="Phone-min.js"></script>
 
</head>
<!-- Establish connection on page load -->
<body>
    <!-- Call to WCS2 on click by this link -->
    <a href="#" on onclick="connect();return false">connect</a>   
</body>
</html>

 

Script

 

//Init WCS JavaScript API

var f = Flashphoner.getInstance();

f.addListener(WCSEvent.ErrorStatusEvent, errorEvent);

f.addListener(WCSEvent.ConnectionStatusEvent, connectionStatusListener);

f.addListener(WCSEvent.RegistrationStatusEvent, registrationStatusListener);

f.init({});

 

//New connection

function connect(){

    f.connect({urlServer:'ws://192.168.1.5:8080',appKey:'defaultApp'});

}

 

//Connection Status

function connectionStatusListener(event) {

    trace(event.info);

    if (event.status == ConnectionStatus.Established){

        trace('Connection has been established. You can start a new call.');

    }

}

 

//Registration Status

function registrationStatusListener(event) {

    trace(event.info);

}

 

//Error

function errorEvent(event) {

    trace(event.info);

}

 

//Trace

function trace(str){

    console.log(str);

}

 

So the page establishes connection to the server and registers at the SIP-server using the SIP-data provided via the REST API.

 

Forbidding access at Web-server's side

 

Suppose, the Web-server decided to not give access to a certain client. In this case, the Web-server should return an error status, for example, 403 FORBIDDEN.

Again, we use mod rewrite to return the error status if the REST API 'connect' method is invoked. Add the following line to .htaccess:

 

RewriteRule ^defaultApp/connect - [F]

 

This force Apache to return 403 FORBIDDEN, for example, in response to the following query: http://flashphoner.com/defaultApp/connect

 

Now we test again and try to connect to the server. As expected, connection fails.

 

In Websocket frames we can see the following: {"message":"fail","data":[{"status":"FAILED","info":"Forbidden","apiMethod":"ConnectionStatusEvent"}]}. The debug console of a browser displays the 'Forbidden' status.

We received a ConnectionStatusEvent event from the client, the event has the FAILED status and the description says Forbidden. Authentication was unsuccessful, and this is exactly what we needed.

 

Dynamic scripts

 

As shown above, it is very simple to make the REST API work. Your web-server must merely provide specific URLs returning the corresponding JSON-objects. In the examples above we used static .json files. However, nothing can stop you from using dynamic PHP scripts or any other available web technologies. Just don't forget to return the Content-Type: application/json header. All server scripts such as PHP, JSP, ASP, Rails, CGI and others can do this. The list of available REST-methods and their description can be found in Web Call Server - Call Flow manual.