Sok weboldalon látni beépülő modulokat, amiknek az anyagát más honlapok szolgáltatják. Gondolok itt többek között a facebook dobozaira, csak hogy egy elterjedtebbet említsek. Ezek egy belső keretben, iframe-ben jelennek meg, hogy a megjelenítő holnap scriptjei ne férhessenek hozzá a modul adataihoz közvetlenül, és így – bizonyos fokig módosíthatóan, de mégis – egységes képet mutassanak mindenhol.

Ha egy hasonló modult kínálunk mi is a partnereinknek valamilyen szolgáltatással, akkor hamar felmerül a kérdés: mekkora méretű helyet kérjek a modulnak, hogy minden tartalom szépen elférjen?

Ennél is körülményesebb annak a megoldása, hogy a modulban végzett eseményeket a partner követni tudja a saját honlapján – például keresési mutatók alapján szeretné testre szabni a tartalmat.

A feladat darabjai

  • a partner honlapján iframe-ben megjelenik egy modul, amit a mi saját szerverünk szolgáltat, a tartalma pedig egy kitölthető űrlap, valamilyen releváns tartalommal kapcsolatban
  • mi mindenképpen feldolgozzuk az összes űrlapot, így van adatunk arról, hogy ki mikor és melyik honlapon keresztül küldött nekünk információkat
  • a partnerünk is szeretne tudni legalább annyit, hogy melyik látogatója töltötte ki és küldte be nekünk

A feladatnak nem egyetlen lehetséges megoldása van, de mindegyik másféle előkészületet és technikai felkészültséget igényel.

A későbbi példák megértéséhez tegyük fel, hogy a két domain szerver.local és partner.local.

A beágyazó kód a partnernél pedig valami hasonló:

(a kód nem érvényes html, a lényeges részekre szorítkoztam)

[...]
<iframe src="http://szerver.local/modul.html" width="320" height="240">
<script type="text/javascript">
function saveEvent () {
  // funkció egy esemény mentéséhez
  // ahogy a partner kezelni szeretné
  [...]
  alert("Esemény történt");
}
</script>
[...]

Alapesetben a modul kódja szimplán megjeleníti az űrlapot, és elküldi a szerverre, ha valaki kitölti:

<form action="http://szerver.local/process.php">
[...]
<input type="submit" value="Elküld!" />
[...]
</form>

Brute force (pull)

Egy nem túl szép – de működőképes – megoldás, ha a partnernek lehetőséget adunk az adatbázisunkból lekérdezni a szükséges minimális adatokat. A hátulütője, hogy a partner oldal felől bizonyos időközönként le kell kérdezni az adatbázist, hogy történt-e esemény, és amennyiben igen, azt külön kell majd válogatni felhasználókra is (ez már történhet a partner oldalán is, akkor legalább válogatni nem nekünk kell).

XSS api "nyers erő" megoldásaEz egyrészt folyamatos adatforgalmat generál a két szerver között, valamint sok partner esetén jelentős megterhelést jelenthet a mi szerverünknek, az egyéb feladatain felül kiszolgálni ezeket a kéréseket is.

A megoldás habár működőképes, elég nehezen skálázható, valamint új partnerek esetén újra kell számolni a rendelkezésre álló erőforrásokat, és esetleg fejlesztéseket kell eszközölni.

Elegánsabb megközelítés

Mivel én magam sem vagyok egy kimondott Vasember alapanyag, ezért jobb szeretem az eszemet használni. Éppen emiatt sokkal jobban tetszik a következő megközelítés: akkor és csak akkor informáljuk a partnert egy eseményről, amikor az ténylegesen bekövetkezik. Ennek is kétféle megközelítése lehetséges, vegyük sorban:

Szerverek közötti kommunikációval (push)

A neve is mutatja, a két szerver kommunikál egymással, de nem a partner kérdezi le, hogy van-e új esemény, hanem mi szólunk neki, amikor van.Ennek a megvalósítása lehetséges egy callback hívással, amikor a feldolgozó php (perl, asp, cgi, …) futása során meghív egy url-t a partner szerverén, ezen keresztül átadva a megfelelő adatokat.

Ez már egy fokkal jobb megközelítés, mint a pull, mert lezártuk azokat az eseteket, amikor “eseménytelen” kommunikáció zajlik a két szerver között, feleslegesen terhelve a hálózatot.

XSS api szerverek közötti kommunikációval

Javítani azonban még mindíg lehet rajta, ugyanis minden beérkező űrlapra jut egy kifelé irányuló kapcsolat is, amin keresztül átadjuk az adatokat a partner felé (még mindig a saját szerverünk terhére). Ezt pedig úgy tudjuk kiküszöbölni, ha a felhasználó kliense adja át ezeket az adatokat a modulból a partner felé, ezzel tehermentesítve a mi szerverünket (és egyben elosztva az ezzel járó erőforrásigényt).

A következő oldalon lesz erre egy konkrét példa is …

(A képekért külön köszönet illeti Jakub Steiner-t, aki elérhetővé tette a darabjait Creative Commons Attribution, Share Alike licensz alatt.)

Oldalak: Következő oldal