Határozza meg a VPN-műveletet, mielőtt API-kat hasonlít össze

Egy termékoldal azt állítja, hogy van API-ja, és az integrációs megbeszélés elakad a második kérdésnél. Melyik művelet, melyik objektumon, ki hívja, és mi számít sikernek? Ha ezt a négyet a termékek összehasonlítása előtt megválaszoljuk, az általában kiejti a jelöltek felét. A fennmaradó összehasonlítást is olyasmivé teszi, amit egy teszt eldönthet.

Cserélje az API-val rendelkezik állítást egyetlen műveletre

Az API szállítás, nem képesség. Egy REST-végpont, egy helyi socket és egy parancssori burkoló mind API-nak nevezhető, és nem kínálnak egyenértékű műveleteket.

Írja le a műveletet mondatként, mielőtt megnyitja a dokumentációt.

Egy helyi kapcsolat indítása kliensoldali művelet, előtte egy felhasználóval. Egy eszközprofil kiadása ellátási művelet, mögötte egy leltárral. Egy felhasználó hozzáférésének letiltása adminisztratív művelet, auditnyommal. Ez a három általában különböző komponensekben él, különböző csapatok tulajdonában, különböző jogosultsággal.

Négy mező, amely tesztelhetővé teszi a szerződést

Töltsön ki négy mezőt minden művelethez: az objektumot, a műveletet, a hívót és a siker feltételét. A hiányzó mezővel rendelkező szerződés csak kívánság.

A táblázat az egész munkalap:

A siker feltétele az a mező, amelyet az emberek kihagynak, és ez dönti el, hogy működik-e az integráció. Egy elmentett beállítás nem aktív alagút, és egy letiltott fiók nem lezárt munkamenet.

Ha két művelet különböző hívókat igényel, az két integráció. Egyetlen szolgáltatásfiókba vonásuk általában több jogosultságot ad, mint amennyire bármelyiknek szüksége van.

Igazítsa az interfészt a tényleges rétegéhez

Az OpenVPN közösségi kezelői interfésze TCP-n vagy Unix socketen keresztül beszél egy daemonnal. Parancsai közé tartozik az állapotmegfigyelés és a daemonnak küldött jelzés.

Ez daemon-vezérlő csatornává teszi, nem hosztolt előfizetéses API-vá és nem felhasználóregisztrációs szolgáltatássá. Dokumentációjának gondos olvasása megkímél attól, hogy olyan rétegre építsen, amely nem birtokolja az objektumot.

Ugyanez a dokumentáció azt is mondja, hogy a protokoll nem hordoz saját titkosítást. Aki eléri a socketet, vezérelheti a daemont, ezért kezelje érzékeny vezérlésként, nem metrikafolyamként. Kösse loopbackhez vagy Unix sockethez, és tegye korlátozott elrendezés mögé, ha távoli hívónak szüksége van rá. Kényelemből az internetre tenni a vezérlőcsatornát incidenssé változtatja.

Határozza meg a hívás utáni viselkedést

Az elfogadás nem ugyanaz, mint a befejezés. A daemon visszatérhet, mielőtt az alagút feláll, ezért várjon a dokumentált befejezési vagy hibaeseményre, és kapcsolja vissza az elküldött kéréshez.

Döntse el, mit tesz a hívó, ha a válasz elveszik. Egy létrehozás vagy újracsatlakozás vak ismétlése nem ugyanaz, mint ellenőrizni, hogy az első kérés már hatott-e.

A hozzáférés eltávolítása legalább három különböző művelet: a jövőbeli bejelentkezés blokkolása, egy élő munkamenet megszüntetése és a hitelesítő adat visszavonása. Azt kérje, amit a szabályzat valóban megkövetel, és mondja meg a szerződésben, melyik melyik. Ne nevezzen egyetlen sikeres fiókfrissítést teljes visszavonásnak bizonyíték nélkül. A különbség incidens közben számít, amikor az óra jár.

Tesztelje a szerződést pilottal

Egy kis jóváhagyott pilotnak le kell fednie a sikert, az elutasítást, a megszakítást és az újrapróbálkozást, majd az alkalmazásműveletet, amelyet engedélyezni vagy tiltani kell.

Daemon szintű interfész esetén két parancs gyakorolja a megfigyelést és egy jelzést:

echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505

Csak a művelethez szükséges jogosultságot adja meg. Tartsa a titkokat a rutinnaplókon kívül, és naplózzon elég személyes részletet ahhoz, hogy megmondja, melyik cél sérült, és hogyan végződött.

Írja le a helyreállítási útvonalat arra az esetre, amikor maga a vezérlő API nem elérhető. Azt az interfészt válassza, amely az objektumot és annak életciklusát birtokolja; a termékoldali automatizálási állítások nem helyettesítik.