0

MobileFirst 7.1 で、ユーザーが時々認証/ログインできないという奇妙な状況に遭遇しています。何かが間違っていることを示す唯一の兆候は、console.log のメッセージです。

[AUDIT ] CWWKS1100A: ユーザー ID の認証が成功しませんでした。無効なユーザー ID またはパスワードが指定されました。

私のカスタムログインモジュールは使用していますcom.worklight.core.auth.ext.LdapLoginModule(明確にするために、LDAPを使用して認証するログインモジュールがあります)。私が言ったように、ほとんどの場合すべてが機能しているように見えますが、ユーザーが認証できない状況に陥ることがあります。おそらく何らかの形でセッションに関連していると思われますが、それは私の調査に基づく推測にすぎません。

セッション状態をに出力する「シークレット」アダプタにログを追加しましたconsole log。これは明らかに、logs上記の失敗した認証メッセージの直前に表示されますが、空です。セッションには何も含まれていません。ユーザーは明らかに、この時点でセキュア アダプターにアクセスしようとしています。認証されていないため、ログイン ページに行き着きます (フォーム ベースの認証についても説明します)。

とにかく、セッション データがないように見えますが、jsessionid がそこにあり、変更されていないことに気付きました。つまり、ブラウザを更新しても変更されません。もちろん、これ自体は問題ではないかもしれませんが、興味深いことに、このエントリを削除してブラウザを更新すると、正常にログインできます。

私のハンドラーコードがsuccess/failure適切な場所で関連するメソッドを呼び出すことは間違いありませんが、もちろん、ユーザーがブラウザーを更新するのを止めるものは何もないため、ユーザーはログインページにリダイレクトされます (アプリは AngularJS を使用して開発されています)事実上、単一ページのナビゲーション モデルです)。

私が思いついた唯一の再現可能なテストは、MobileFirst コンソールにログインしてから、MF「デスクトップ・ブラウザー」アプリにログインしようとしたときです。この状況がセッション関連の競合を引き起こすことを読みましたが、私が目にする時折の問題は、これが原因ではありません (関連している可能性があります)。

4

1 に答える 1

0

したがって、この問題は、MF プラットフォーム固有の問題よりも、ログインに成功した後のアプリケーションのロジック フローに関連しているようです。

たとえば、ユーザーがブラウザーを更新すると、事実上ログインしたままになりますが、(開発したロジックに基づいて) アプリは更新時にユーザーをログイン ページに移動させるため、ユーザーは実質的に同じセッションに再ログインします。これが毎回失敗した場合、もちろん特定するのは簡単だったでしょうが、そうではありません。解決策は、更新時 (アプリの初期化時) に強制的にログアウトし、セッション データをクリーンアップすることでした。もちろん、将来の反復では、リフレッシュ後に認証されたセッションに基づいてアプリケーションを再確立する方が良いかもしれませんが、現時点ではそれは行き過ぎでした。

これの別の例は、後続のアダプター呼び出しが失敗した場合 (たとえば、認証してからデータベースからプロファイル データを取得した場合) のポスト ログインで、認証に成功したユーザーもログアウトしていませんでした。

于 2016-03-08T10:00:41.557 に答える