ugrás a tartalomhoz

SOA és jogosultságok

inf · 2010. Jún. 28. (H), 05.01
Üdv.

Az érdekelne, hogy hogyan szokás webserviceknél jogosultságot kezelni?
Hogy kézzelfogható legyen, írok egy konkrét példát:
class ForumService
{
void login(String email, String password);
List<Comment> getAll();
void put(Comment value);
}

Itt a login és getAll action-ök használatára alapból mindenkinek joga van, viszont a put action használatára csak annak van joga, aki bejelentkezett az oldalon. Na most azt, hogy milyen actiont lehet az adott sessionnel meghívni valahogyan jelezni kell a kliensnek, és engem ennek a mikéntje érdekel.

Előre is kösz a válaszokat!
 
1

Mintha helyi lenne

janoszen · 2010. Jún. 28. (H), 08.27
Mit tennél ha helyi függvényhívás lenne? A webservice layer tulajdonképpen nem más, mint egy távolí függvényhívás objektumátadással úgyhogy jól strukturált program esetén ugyanazokat a checkeket tudod használni mint a webes felületeden.
2

Azért nem teljesen, mert

inf · 2010. Jún. 28. (H), 19.26
Azért nem teljesen, mert spórolni kell azzal, hogy hányszor hívom meg a szervert. Úgy gondoltam csinálok egy SecurityService-t, amitől getPermissionMap-el el tudom kérni az engedélyezett {service1: [action1,action2...], ...} servicek és action-ök listáját. Így szinkronba lehet hozni az oldalt azzal, hogy a szerver mit fogad el. Egyelőre még nem tudom, hogy a wsdl fájlok alapján generáljam a proxy objektumokat a servicekhez, vagy alapból transzformáljam őket xslt-vel a wsdl-ből, és js fájlokból importáljam be őket.
Nem egy elterjedt dolog ajax+php-val soa-zni, mert nem erre találták ki soa-t. Mindenesetre jobb, mint postData-t parsolni, és minden egyes Controllert(servicet) kézzel megírni.
3

Bugos

janoszen · 2010. Jún. 28. (H), 20.49
A PHP SOAP interfészében vannak ordenáré nagy bugok, nem biztos hogy nagyon érdemes rá építeni.

Ami az access controlt illeti: próbáld meg úgy szervezni, hogy a SOA hívások egy-egy controllerben kössenek. Innentől fogva vagy a controllernek vagy a modellnek úgyis kell autorizációt ellenőrizni, pusztán a GPC paraméterek parzolását kell kihagyni.

Erről egyébként Felhő tudna többet mondani, de sajnos keveset jár erre.
4

Persze, én is úgy gondoltam,

inf · 2010. Jún. 29. (K), 00.17
Persze, én is úgy gondoltam, a ServiceBus a FrontControllernek, a Servicek meg az egyes Controllereknek felelnek meg. Úgy szeretném megcsinálni, hogy az átvitt adat pedig Model objektumokba kerüljön, ehhez először megcsinálom a Model osztályoknak megfelelő xsd-t, aztán arra teszek restriction-t minden egyes action-höz. Egyelőre még nem tiszta, hogy hogyan fogom elérni, hogy a restriction-re is a Model osztályt használja, és ne kelljen restriction osztályt létrehozni, de biztosan meg fogom oldani. :-)

Lesz a Session-ben egy SecurityService, amitől le tudja kérdezni a service bus, hogy megvan e a jogosultság, aztán ha nincs, akkor exceptiont dob, így nem jut el a Service-ig a kérés. Meg ugyanennél lesznek külső elérésű dolgok is, úgy, mint login, loginPermanentCookie, getPermissionMap meg ilyesmik...

Ezzel a rendszerrel szerintem nagyon jól átlatható lesz az egész validálás, csak nagyon kevés dolog lesz, amit manuálisan kell megoldani, szóval sokkal egyszerűbb lesz biztonságos oldalt írni, meg a View részt teljesen le lehet választani a szerverről.
5

Valóban

inf · 2010. Júl. 7. (Sze), 12.49
A PHP SOAP interfészében vannak ordenáré nagy bugok, nem biztos hogy nagyon érdemes rá építeni.


Hát eddig kettőt találtam:
- Nem ellenőrzi az XML Schema alapján az átvitt adatot, szóval gyakorlatilag nem validál, így bármit át lehet hozni
- Nincs normális megoldás az áthozott adat objektumokra való alakítására, lehet megadni classMap-et meg typeMap-et, de olyat nem lehet, hogy egy függvénynek passzolod le a konvertálást, így gyakorlatilag lehetetlen általános konvertálót beleírni. (Gondolok itt olyanra, hogy a típusokat ugyanúgy nevezem el, mint az osztályokat egy névtérben, aztán csak megadom a névteret, a konverziót meg automatikusan végrehajtja a rendszer.)

Pocsék... Valszeg írok egy saját egyszerű valamit a témára, vagy váltok java-ra, mert már kezdem unni, hogy php-ben nincsen semmihez használható eszköz.
6

Másik

janoszen · 2010. Júl. 7. (Sze), 12.54