WSF/PHP Demo Site contains number of applications that demonstrate the different features of WSO2 WSF/PHP in practice. Calendar Service is one of such application. It demonstrate the use of WSDL Mode for a service with different policies for different operations + the use of Username tokens.
You can view the source code of the Calendar Service from here.
The username token is provided as an arguments to the WSService constructor at the end of the service script.
// our security token $security_token = new WSSecurityToken(array("passwordCallback" => "get_password", "passwordType" => "plain")); // create service in WSDL mode $service = new WSService(array ("wsdl" =>"Calendar.wsdl", "actions" => $actions, "classmap" => $class_map, "securityToken" => $security_token, "operations" => $operations)); // process client requests and reply $service->reply();
We use a callback function (“get_password”) to validate the user and give that function name to the securityToken object constructor. Inside that callback function, we retrieve the password for the user from a database call. Here is the code inside the callback function that is again extracted out from the calendar service.
/** * call back function. * verify the validity of user enterd password with * the actual password which is kept in the database. */ $current_username = ""; function get_password($username) { $dbhost = DB_HOST; $dbname = DB_NAME; $dbuname = DB_USERNAME; $dbpass = DB_PASSWORD; $link=mysql_connect($dbhost, $dbuname, $dbpass); mysql_select_db($dbname, $link); $sql="SELECT password FROM `customer_details` WHERE `user_name` = '".$username."'"; $result=mysql_query($sql,$link); $password=mysql_fetch_array($result, MYSQL_NUM); global $current_username; if($password) { $current_username = $username; return $password[0]; } else { $current_username = ""; return NULL; } }
So for all the operations which require authentication like login, getEvents, deleteEvents and addEvent, the WSF/PHP engine validate the user before invoking the operation. If the authentication fails, the engine will send a SOAP fault with the fault details. But in this service there is a operation which doesn’t require authentication. That is the ‘register’ operation. Because until the registration complete you can’t have a username password, so we should not authenticate that ‘register’ operation. So we need to provide a different policy for the ‘register’ operation.
The policies for each of the operation is declared in the Calender.wsdl itself. If you look at the WSDL you can see each of the policies required by the operations are declared inside the policy elements as mentioned in WS-Policy Specification. And each of the operation refers the corresponding policy element from the binding section of the WSDL.
You can see how it is done for login (which requires authentication) and the register (which doesn’t requires authentication) from the code below.
<wsdl:operation name="login"> <soap12:operation soapAction="urn:login" style="document"/> <wsdl:input> <wsp:PolicyReference URI="#username_token_policy"/> <soap12:body use="literal"/> </wsdl:input> <wsdl:output> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="register"> <soap12:operation soapAction="urn:register" style="document"/> <wsdl:input> <soap12:body use="literal"/> </wsdl:input> <wsdl:output> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation>