IBM MobileFirst 7.1 拒絕存取

延續之前 MobileFirst 7.1 的 Server Farm 機制無法正常啟用，經過好一陣子與 IBM Lab 之間的往返，還是沒有一個好的解決方案。

所以，只好考慮直接裝一套新的 Server，並且把專案移轉到新的伺服器上來。
但是，在移轉之後卻出現如上圖所示的錯誤。

因為，通常我們會在 App 啟動時，使用 WL.Client.connect 與 MobileFirst 伺服器連線，以確認 Client 與 Server 之間的版本，並檢查管理者有沒有設定任何通知訊息。

但是，在移轉後，App 端會出現「Access Denied」的錯誤，無法正常啟動 App。

伺服器端，也可以觀察到下列的錯誤訊息：

FWLSE0335E: Authorization failed: 
ClientId f5ac9a8cda443cfca33d1e7f926a71f90f8c67a1 was not found 
on the server.

這個情況，可以透過移除該 App 並且重新安裝，來解除此問題。

所以，我們大概可以推測，MobileFirst 的 Client 端在跟 Server 連結之後，會在手機端留下一些資訊。這些資訊，應該是 MobileFirst 用來確保安全的機制。

1. 可以避免，我們連接到的 Server 與之前的不同
2. 從伺服器端的角度來看，如果先前該手機已經跟伺服器註冊過。但是，現在我們卻無法在伺服器上找到該 ClientId 的話。這個裝置是不是該被視為有問題的裝置。

當然，這種安全機制，有時候還是會造成我們的困擾。

所以，為了避免要求大量使用者重新安裝 App，我們可以採取下列兩種方案，來解決此問題。

1. 在 MobileFirst 7.1 之後，與先前開始有所不同，採用 Session Independent 作為伺服器運作的預設機制。當採用 Session Independent 時，MobileFirst 的相關資訊就會被存於資料庫中。所以，必須調整 MobileFirst 處理 Session 的機制，讓資訊是存於記憶體之中。這樣，就可以解決上述遇到的問題。但是，當採用這樣的機制，勢必會影響到後續 Server 做平行的擴充。所以，除非是以單一機器提供服務，不然不建議採用這個解決方案。

2. 既然，App 移除重裝之後就可以解決此問題。那麼，就是需要在程式中加上一段清除手機上暫存的這些資訊，如此就可以使 App 恢復正常運作。經測試，先前假設沒錯，就是有一段資料被存在手機上。移除之後，就可以正常與伺服器連線。

「參考資料」
1. MobileFirst 7.1 Server Access Denied when using WL.Client.connect API