我工作在現有的J2EE應用程序和我需要刪除一些供應商的特定方法從代碼中調用中獲取用戶信息。如何在無狀態會話bean
會話門面背後的DAOS撥打電話到EJB容器來獲取用戶的ID和密碼 - 爲了連接到數據庫。用於連接到服務器的initialContext的用戶標識和密碼部分。
我能夠得到使用sessionContext.getCallerPrincipal（）的用戶ID
反正是有得到連接到服務器上使用的SECURITY_CREDENTIALS或者，有沒有辦法從服務器連接到EJB的傳遞信息（它們都是無狀態的會話bean）。
這是一個既有豐富客戶端又有Web前端的大型應用程序，在完美的世界中，我很樂意回頭重新構建整個解決方案以使用J2EE安全性等 - 但不幸的是，是不現實的。
通常情況下，Java EE的安全模型將不允許用戶密碼的檢索，出於安全原因。但這取決於實施。一些供應商提供的方法來獲取這種信息，但如果依靠這樣的實現，要知道，應用程序的可移植性將受到損害。
一種常見的方法是寫一個Servlet過濾器攔截登錄請求，並保存憑證的副本，以供以後使用。如果您的應用程序不使用Java EE安全基礎架構，則可以輕鬆實現。這是因爲一些供應商阻止您過濾認證servlet。
我不能給你一個通用的解決方案，但是這是爲我們工作。我們將應用服務器作爲特定用戶連接到LDAP，以便爲其他用戶請求憑據。然後，我們可以使用一些通用安全代碼，根據初始登錄時的用戶身份（就像您通過getCallerPrincipal（）執行的操作）一樣，可以使用通用安全代碼從會話Bean內部請求用戶憑據。
我們還將用戶標識放置在線程局部變量中，以便EJB中調用鏈的類不必是「容器感知」的。他們只需從本地線程訪問身份並使用安全類來查找用戶配置文件信息。這也使得更改測試實現變得很容易，甚至可以輕鬆更改LDAP查找以外的其他實現。
我們創建的其他便利是一個JDBCServiceLocator，用於檢索與當前用戶的用戶/密碼的連接。所以開發人員根本不必顯式編碼安全性查找。
羅賓，
聽起來就像我的計劃。我想我會在成功的服務器連接之後立即打電話將憑據加載到我的連接類的threadLocal變量中。我希望有一個更簡單的方法 - 但我猜不是。