[已回復] 求教關于MobileIMSDK服務端sdk安全驗證方面的一些問題

1.登錄模塊alreadyLogined分支，PLoginInfo沒有經過業務端的回調驗證就直接拿來使用
測試：使用A用戶加上正確token正常登錄，再使用B用戶加上隨意token登錄竟然也成功了（應登錄失敗）
2.客戶端發來的Protocal中的from沒有判斷，應該判斷是否和session的登錄id是否一致

默認的sdk因為考慮到算法本身的可讀生、簡潔性等，所以盡量走的普通的安全場景，讓研究算法的人盡量把焦點放到通信算法本身，是這樣的思路。

你可以按照你的場景安全要求，進一步深入強化，有必要，可以改寫源碼，這也是開源的便利。

第一個登錄問題，個人認為還是很有必要，不然登錄回調接口留著就沒有意義了

第二個from驗證的話，因為我這邊業務只有單聊，發送消息必須先經過服務端的messageReceived，個人認為本不應該從客戶端帶上from，而直接使用session保存的登錄id

引用：xkadxd 發表于 2019-11-06 15:53
第一個登錄問題，個人認為還是很有必要，不然登錄回調接口留著就沒有意義了

這個服務端的回調接口已經留好了，自已加上你的驗證邏輯就行了，默認肯定沒辦法決定你的邏輯是什么，具體你看這個回調：ServerEventListener. onVerifyUserCallBack(..)，詳細看一下api說明。

引用：JackJiang 發表于 2019-11-06 16:18
這個服務端的回調接口已經留好了，自已加上你的驗證邏輯就行了，默認肯定沒辦法決定你的邏輯是什么，具體 ...

這些我了解。我指的是alreadyLogined分支沒有調用ServerEventListener. onVerifyUserCallBack(..)

引用：xkadxd 發表于 2019-11-06 16:22
這些我了解。我指的是alreadyLogined分支沒有調用ServerEventListener. onVerifyUserCallBack(..)

那不行，如果業務層實現時onVerifyUserCallBack的邏輯復雜的話，每個包都這樣調用性能成本太高了，你了解一下這個：《即時通訊安全篇（七）：用JWT技術解決IM系統Socket長連接的身份認證痛點》，用JWT可以很好的解決，性能也能承受。

引用：JackJiang 發表于 2019-11-06 16:45
那不行，如果業務層實現時onVerifyUserCallBack的邏輯復雜的話，每個包都這樣調用性能成本太高了，你了解 ...

有點理解了，IMsdk里的login主要是通訊層的login，斷線等多種情況下客戶端會自動重新login，為了性能考慮所以在已登錄情況下不驗證重復登錄的信息

基于這種情況我認為：在session已登錄A賬號的情況下，客戶端發來重新登錄的請求，可以不驗證。但是也不要使用發過來的userid替換session里的userid。如果客戶端需要切換用戶，那么必須先logout再重新登錄B賬號。