WordPress-identitási döntés
Amazon Cognito kontra WordPress natív hitelesítés
A valódi kérdés nem az, melyik bejelentkezési űrlap néz ki jobban. A döntés arról szól, hogy a látogatói identitás a WordPress-alkalmazáshoz tartozzon-e, vagy statikus oldalakon, föderált szolgáltatókkal és védett API-khoz is használhatónak kell maradnia.
Rövid összegzés Használjon WordPress natív hitelesítést, ha maga a WordPress az alkalmazás határa. Cognitót és Gateyt akkor válasszon, ha az alkalmazásidentitásnak a statikus közzététel után is működnie kell, közösségi vagy SAML/OIDC-szolgáltatókkal kell föderálnia, illetve WordPressen kívüli API-kat kell engedélyeznie.
A döntés
Döntse el, hol marad mérvadó az identitás
A bejelentkezés, a fiókállapot és az API-jogosultság nehezen követhetővé válik, ha tudatos identitáshatár nélkül több rendszer között oszlik meg.
Futási környezet
A WordPress-munkamenetekhez a WordPressnek kell kiszolgálnia a kérést
Ez természetes a dinamikus WordPressnél, de nem illik olyan nyilvános frontendhez, amely statikusan kerül kiszolgálásra, és az oldalmegtekintésekhez már nem hív PHP-t.
Föderáció
A külső identitásszolgáltatók kitágítják az alkalmazás határát
A közösségi szolgáltatókat és az egyedi SAML/OIDC-föderációt egyszerűbb egységes alkalmazásidentitásként kezelni, ha a Cognito a központ, mint minden webhelyfelülethez külön bejelentkezési logikát hozzáadni.
Jogosultságkezelés
A webhely-munkamenet nem azonos az API-jogosultsággal
A védett API-knak tokenre, IAM-re vagy más, backend által kikényszerített mechanizmusra van szükségük, amely a látható WordPress-szerepköröktől és gomboktól függetlenül ellenőrizhető.
A döntés következménye Tartsa meg a WordPress natív felhasználóit, ha az alkalmazás határa a WordPress. Helyezze át a látogatói identitást a Cognitóba, ha ugyanannak az identitásnak frontend-, API- vagy föderációs határokon is át kell nyúlnia.
Egymás mellett
Az identitás működési modelljének összehasonlítása
Mindkét modell érvényes. A jobb illeszkedés attól függ, hogy a hitelesítés állapotának hol kell használhatónak maradnia a belépés után.
| Döntési szempont | Amazon Cognito + Gatey | WordPress natív hitelesítés |
|---|---|---|
| Frontend futási környezet | A Gatey a böngészőben, a Cognitón keresztül hitelesít, ezért a támogatott bejelentkezési, regisztrációs, MFA-, jelszó-visszaállítási és profilfolyamatok statikus export után is működhetnek. | A natív felhasználók és munkamenetek élő WordPress-környezethez illenek, ahol a PHP és a WordPress-adatbázis elérhető marad a hitelesített kérésekhez. |
| Föderáció és API-k | A Cognito közösségi és egyedi SAML/OIDC-szolgáltatókkal föderálható. A Gatey az így létrejött identitást JWT- vagy IAM-alapú API-hozzáféréshez használhatja. | WordPress-bővítményekkel SSO- és API-minták adhatók hozzá, de további architektúra nélkül a natív felhasználói és munkamenetmodell továbbra is a WordPress köré épül. |
| Üzemeltetési illeszkedés | Akkor megfelelő, ha az identitás statikus oldalak, API-k vagy több felület által használt alkalmazásszolgáltatás, és a csapat vállalja a Cognito üzemeltetését. | Akkor megfelelő, ha maga a WordPress az alkalmazás, és a meglévő bővítmények natív felhasználókra, szerepkörökre és munkamenetekre támaszkodnak. |
Melyik identitásmodell illik a projekthez?
Válassza a Cognitót és a Gateyt
Amikor az identitás túlmutat a WordPressen
- A nyilvános frontend lehet statikus, miközben a látogatóknak továbbra is bejelentkezésre, regisztrációra, MFA-ra vagy profilkezelésre van szükségük.
- Ugyanazoknak a felhasználóknak védett API-kat kell elérniük, vagy közösségi, SAML- vagy OIDC-szolgáltatókon keresztül kell föderálniuk.
- A WordPress maradjon CMS és megjelenítési réteg, ne az alkalmazás identitás-adatbázisa.
Válassza a WordPress natív hitelesítést
Amikor a WordPress már eleve a megfelelő identitáshatár
- A webhely hagyományos, dinamikus WordPress-alkalmazás marad.
- A tagsági vagy bővítményműködés közvetlenül a WordPress felhasználói azonosítóitól, szerepköreitől és munkameneteitől függ.
- Nincs szükség külön identitásszolgáltatásra, statikus frontend-bejelentkezésre vagy alkalmazások közötti API-identitásra.
Problémaközpontú útmutatók
Folytassa az identitásproblémából kiindulva
Mikor legyen a Cognito az alkalmazás identitási rétege?
Kezdje az Amazon Cognito használata a WordPress helyett alkalmazás-identitási rétegként útmutatóval, majd a megvalósítás határainak kialakításához használja a Cognito Day-2 identitásarchitektúra WordPresshez oldalt.
Hogyan adható bejelentkezés statikus WordPresshez PHP-munkamenetek nélkül?
Tekintse meg a Bejelentkezés hozzáadása statikus WordPresshez a PHP-munkamenetek visszahozása nélkül útmutatót. A Gatey a támogatott hitelesítési folyamatokat a böngészőben, a Cognitón keresztül végzi, így a nyilvános oldalnak nincs szüksége WordPress-munkamenetre.
Hogyan csatlakoztathatók meglévő SAML- vagy OIDC-identitásszolgáltatók?
Használja a WordPress csatlakoztatása meglévő SAML- és OIDC-identitásszolgáltatókhoz külön bejelentkezési folyamatok építése nélkül útmutatót. Az egyedi SAML/OIDC-szolgáltatók a Gatey Pro Cognitón keresztül konfigurálható képességei.
A sikeres bejelentkezés automatikusan engedélyezi az API-kat vagy a védett fájlokat?
Nem. A védett API-knak JWT-t, IAM-et vagy más megfelelő backend-jogosultsági mechanizmust kell ellenőrizniük. A védett statikus útvonalak külön CloudFront-hozzáférési határral rendelkeznek.
Először az identitáshatárt válassza ki
Használjon Cognitót, ha az identitásnak a WordPress-munkameneten kívül is használhatónak kell maradnia
Induljon ki az alkalmazásidentitás problémájából, vagy használja a statikus bejelentkezési útmutatót, ha az azonnali cél a PHP-munkamenetek eltávolítása a nyilvános frontendről.