Da bi koristio Zend_Soap, ne moraš i ne trebaš da ulaziš u ceo Zend Framework, jer on je, kao i npr. Symfony2, glue framework, component-based, što znači da nisi primoran da koristiš sve komponente framework-a, niti da ih koristiš na neki unapred definisan način, kao što je to slučaj kod full-stack framework-a.
Zend_Soap_Server komponenta poseduje jednu jako korisnu funkcionalnost -
Autodiscovery. S njom npr. možeš da imaš sledeće:
Code:
if (isset($_GET['wsdl'])) {
$autodiscover = new Zend_Soap_AutoDiscover();
$autodiscover->setClass('ServisKlasa');
$autodiscover->handle();
} else {
$soap = new Zend_Soap_Server("http://www.test.com/soap.php?wsdl");
$soap->setClass('ServisKlasa');
$soap->handle();
}
Dakle, endpoint tvog SOAP servisa je upravo stranica na kojoj ćeš imati ovaj kôd, u ovom primeru
http://www.test.com/soap.php. Pritom, ako na tvoj SOAP servis dođe zahtev sa tim
wsdl parametrom u URL-u, automatski će biti generisan XML WSDL-a kao output. S druge strane, na tom endpoint-u, Zend_Soap_Server osluškuje i reaguje na SOAP request-ove, a WSDL uzima upravo sa istog tog URL-a, samo sa pridodatim
wsdl parametrom. Za "ServisKlasa" ti je pretpostavljam sve jasno, to je ta neka klasa koja sadrži metode koji će se mapirati u API tog tvog SOAP servisa.
Inače, interno, Zend_Soap_Server ne "izmišlja toplu vodu", već praktično samo wrap-uje onu PHP-ovu
SoapServer klasu.
A ono što je tebe zanimalo je to pitanje autentifikacije...
Ovde imaš primer kako je to realizovano u okviru jednog servisa baziranog na Zend_Soap_Server komponenti. Dakle praktično ono što klijent mora da uradi, jeste da pre svakog request-a, poziva taj neki
authenticate metod kojeg bi ti definisao u svom servisu.
Drugo rešenje koje ja vidim je da npr. svaki metod tvog servisa formiraš na način da umesto više parametara, prihvata samo jedan, npr.
$data, u kome bi bili svi parametri u key-value formi, ali bi kao poslednji parametar imao taj neki
$signature. Npr. ovako bi izgledali potpisi metoda:
Code:
public function addUser($data, $signature) { ... }
A taj
$signature bi bio recimo
md5 od svih naziva
$data parametara i njihovih vrednosti, sa dodatkom tog nekog tajnog ključa, koji bi bio praktično salt, a koji bi bio poznat samo tebi i tom nekom klijentu za kojeg praviš servis. Dakle ovako bi u slučaju tog metoda morao da bude formiran zahtev na tvoj servis:
Code:
$secretSalt = 'key111222333';
$signature = '';
foreach($data as $key => $val) {
$signature .= $key . $val;
}
$signature = md5($secretSalt . $signature);
I onda bi se na servis slala ta dva parametra -
$data i
$signature. Naravno, na serverskoj strani bi onda morao da radiš istu stvar, dakle uzmeš taj $data niz, odradiš build-ovanje signature-a na isti način, i ako se taj $signature parametar kojeg ti je poslao klijent poklapa sa tim što si dobio, znaš da je zahtev validan.
Naravno, postoji i još jedan način za ostvarivanje autentifikacije i uopšte pitanja sigurnosti te API-based komunikacije (verovatno i još koji
), a on se svodi na enkriptovanje te komunikacije, na način da klijent enkriptuje sve parametre koje šalje, opet uz pomoć nekog tajnog ključa, a server radi dekripciju koristeći isti taj ključ. Dakle bukvalno kombinacija npr. PHP-ovih mcrypt_encrypt i mcrypt_decrypt funkcija. To je možda i najbolji mehanizam što se sigurnosti tiče.