connectAs =「endUser」究竟幹什麼？

Question

Worklight文檔refers to an attribute位於適配器XML文件的元素connectAs="endUser"中。它表示這意味着：

到後端的連接是使用用戶的身份創建的。 僅在用於此過程的安全測試 中標識了用戶領域時纔有效。

但是，這對於從適配器到後端HTTP服務器執行的HTTP連接而言意味着什麼？它如何影響，例如，JSESSIONID？

Answer 1

編輯：繼我原來的職位，安東·亞歷山德羅夫提供了一個博客文章對這一機制如何工作的更多細節： https://www.ibm.com/developerworks/community/blogs/worklight/entry/configuring_http_adapters_for_stateless_stateful_backend_connectivity_and_user_identity_propagation?lang=en

---

什麼這實際上意味着，工作燈服務器的行爲就好像它是「最終用戶」（特別是網頁瀏覽器）一樣。

在給定的Worklight適配器中，connectAs =「endUser」參數將導致HTTP Set-Cookie標頭存儲爲經過驗證的Worklight會話的一部分。隨後請求connectAs =「endUser」的請求將發送作爲該「endUser」服務器端會話的一部分存儲的任何cookie。

Worklight文檔特別聲明，它只在領域中有效，因爲如果沒有領域，就不可能保存這些cookie供以後在服務器端會話中使用。

如果您選擇使用此參數，則Worklight客戶端應用程序視角的效果不應改變。

Worklight服務器到後端HTTP服務將改變。本質上，後端服務器會將使用connectAs =「endUser」的Worklight適配器視爲單個HTTP Web瀏覽器。所以對於JSESSIONID的例子：

1. 你啓動的程序「登錄」首次指定connectAs =「終端用戶」。此過程還具有相關的安全測試，該測試強制用戶登錄到某個領域（無論採用什麼方式或匿名 - 只要Worklight具有用於將cookie連接到cookie的用戶會話，則無關緊要）
2. 當此請求到達通過JSESSIONID跟蹤會話的基於Java的服務器，它會檢測到這是首次請求。它將處理該請求，併發送HTTP響應，以及HTTP正文中所需的任何內容。在HTTP標題中，將會有一個包含JSESSIONID的Set-Cookie響應。
3. 憑藉包含connectAs =「endUser」的Worklight過程，Worklight服務器將處理這些Set-Cookie標題，並將它們與用戶對Worklight領域授權的會話一起存儲（這就是爲什麼您需要具有被記錄在該領域工作）
4. 在隨後的請求，過程「mySecondServerProcedure」，其中也有connectAs =「終端用戶」和指定的同一領域，工作燈服務器將自動提供所存儲的除了在適配器的requestHttp（）調用中作爲參數添加的任何cookie外，您還可以在傳出HTTP請求上向服務器發送Cookie。在這個例子中，將提供被設置爲「登錄」一部分的JSESSIONID。
5. 如果你再拍請求的程序「myThirdServerProcedure」，做不已經connectAs =「最終用戶」設置，任何Cookie將提供對即將離任的HTTP響應的服務器，你不手動提供的部分您的適配器中的requestHttp（）調用中的「Cookies」參數。

重要注意事項：

• 用戶必須爲此工作，使工作燈可與會話
• 會話cookie存儲在HTTP Cookie以先登錄纔有效在發出初始請求的適配器內;如果在將上面的JSESSIONID設置爲「login」的一部分後，從另一個適配器運行connectAs =「endUser」請求，則此請求不會將JSESSIONID cookie自動附加到傳出請求。
• 如果您註銷經過身份驗證的Worklight用戶會話，則對這些Cookie的所有引用都將消失。

我的經驗一般規則如下：

• 如果你正在做一些非常簡單的身份驗證，需要在後端服務器上的cookies保持一致，使用終端用戶
• 如果」重做一些更復雜的事情，或者可能要求服務器發送的cookie可以從多個適配器中使用，找到另一種存儲cookie的方式。我喜歡的模式是提供一個包裝器方法，它使傳出的HTTP請求和處理響應中返回的頭部以存儲必要的「全局」屬性。在Worklight世界中，這可以作爲Worklight用戶會話對象的一部分，也可以調用到基礎Java或數據庫存儲實現。