Web應用程式通常提供帳戶管理功能,讓使用者在網站上註冊,如此一來,使用者資料資訊便能持續存在,以便日後登入並享有一致的體驗。 本文說明AEMas a Cloud Service的下列概念:
為了讓本文所述的功能發揮作用,必須啟用使用者資料同步功能,此時需要請求客戶支援指明適當的計畫和環境。 如果未啟用,使用者資訊只會保留一小段時間(1到24小時),之後就會消失。
當一般使用者在AEM應用程式上註冊帳戶時,會在AEM Publish服務上建立使用者帳戶,這反映在下的使用者資源上 /home/users
JCR存放庫中的。
實作註冊的方法有兩種,如下所述。
您可以撰寫自訂註冊代碼,最少需要使用者的使用者名稱和密碼,並在AEM中建立使用者記錄,然後可以在登入期間用來進行身份驗證。 以下步驟通常用於建構此註冊機制:
findAuthorizables()
方法createUser()
方法setProperty()
方法在某些情況下,註冊或使用者建立之前都發生在AEM以外的基礎結構中。 在這種情況下,使用者記錄會在登入期間在AEM中建立。
一旦終端使用者在AEM Publish服務上註冊,這些使用者就可以登入以取得已驗證的存取權(使用AEM授權機制),並持續儲存使用者特有的資料,例如設定檔資料。
登入可透過下列兩種方法實作:
客戶可以編寫自己的自訂元件。 若要進一步瞭解,請考慮熟悉:
客戶可以與IdP (身分提供者)整合,以便驗證使用者。 整合技術包括SAML和OAuth/SSO,如下所述。
基於SAML
客戶可透過其偏好的SAML IdP使用SAML型驗證。 搭配AEM使用IdP時,IdP會負責驗證一般使用者的認證,以及代理使用者對AEM的驗證、視需要在AEM中建立使用者記錄,以及管理使用者在AEM中的群組成員資格,如SAML判斷提示所述。
IdP只會驗證使用者認證的初始驗證,而只要AEM登入權杖Cookie可用,就會使用AEM登入權杖Cookie執行後續請求。
請參閱檔案以取得以下專案的詳細資訊: SAML 2.0驗證處理常式.
OAuth/SSO
請參閱 單一登入(SSO)檔案 有關使用AEM SSO驗證處理常式服務的資訊。
此 com.adobe.granite.auth.oauth.provider
介面可透過您選擇的OAuth提供者實作。
AEMas a Cloud Service已啟用Cookie型粘性工作階段,可確保將一般使用者路由至每個請求上的相同發佈節點。 為了提高效能,封裝權杖功能預設為啟用,因此存放庫中的使用者記錄不需要在每次請求時參考。 如果取代一般使用者與其相似性的發佈節點,則其使用者ID記錄可在新發佈節點上使用,如以下資料同步一節中所述。
根據資料的性質,有多種方法可儲存資料。
使用者設定檔資訊的寫入和讀取方式有兩種:
com.adobe.granite.security.user
介面UserPropertiesManager介面,將資料放置在使用者節點下 /home/users
. 確保不快取每位使用者不重複的頁面。一般使用者資料可以傳送給第三方廠商(例如CRM),並在使用者登入AEM時透過API擷取,並在AEM使用者的設定檔節點上保留(或更新),並視需要供AEM使用。
可以即時存取協力廠商服務以擷取設定檔屬性,但請務必確保這不會對AEM中的請求處理造成重大影響。
發佈層存取原則(也稱為封閉式使用者群組(CUG))在AEM作者中定義為 在此說明. 若要限制某些使用者存取網站的某些區段或頁面,請視需要使用AEM作者套用CUG (如此處所述),並將它們復寫至發佈階層。
獨立於登入,自訂程式碼也可以根據組織的獨特要求保留和管理使用者的群組成員資格。
網站使用者期望在每個網頁請求上獲得一致的體驗,甚至當他們使用不同的瀏覽器登入時,即使他們不知道,也會帶他們到發佈層基礎架構的不同伺服器節點。 AEMas a Cloud Service會透過快速同步 /home
發佈層級所有節點的資料夾階層(使用者設定檔資訊、群組成員資格等)。
與其他AEM解決方案不同,AEMas a Cloud Service中的使用者和群組成員資格同步不使用點對點傳訊方法,而是實作不需要客戶設定的發佈 — 訂閱方法。
依預設,使用者設定檔和群組成員資格同步化不會啟用,因此資料不會同步化至發佈層級,甚至不會永久儲存至發佈層級。 若要啟用此功能,請傳送要求給客戶支援,指出適當的計畫和環境。
已驗證的HTTP請求可能難以在CDN和Dispatcher上快取,因為它們可能會將使用者特定的狀態作為請求回應的一部分傳輸。 不小心快取已驗證的請求並將它們提供給其他請求瀏覽器可能會導致不正確的體驗,甚至洩露受保護的資料或使用者資料。
在支援使用者特定回應的同時維持請求的高快取能力的方法包括: