2017-08-29 3 views
0

ユーザーが既にサービスアプリケーションにログインしている場合にサービスチケットの生成をバイパスできるかどうかは疑問です。CAS - 既にログインしている場合ST生成をバイパスする方法

ケース

  • ユーザーが複数のブラウザタブが同じサービスのためにオープンしました。 (たとえば、ブラウザの起動後)。各タブにはログインウィンドウがあります。
  • 最初のタブで、彼はログイン名とパスワードを提供し、CASサーバーは彼を認証してTGTとSTを生成します。 STが適切に検証され、ユーザーはserviseアプリケーションの内容を確認できます。
  • その他のタブには、CASログインウィンドウが表示されています。
  • ユーザーがタブのコンテンツをリフレッシュすると、CASは新しいSTを生成し、サービスアプリケーションにリダイレクトします。
  • ユーザーがSSOログインURLを使用するたびに、新しいSTが生成されます。 、

    • ユーザがすでにログインしているかどうかを確認する方法はあります:ユーザーが10個の以上のブラウザタブを有している場合には
    • は、STの世代は、ソース

    質問の無駄ですSTの生成をバイパスして、直接サービスにリダイレクトすることができますか?

ログイン後の無限ループには問題がありましたが、1人のユーザーのみが1日に限られました。 TGTのアップデートが多すぎるため、ループによりDBに問題が発生しました。 おそらく、データベース内の恒久性の代わりにメモリ内のチケットレジストリを使用して問題を解決しました。 しかし、ユーザーがすでにアプリケーションにログインしているときにSTの生成を回避する方法がある場合、それは素晴らしい解決策になります。

私が見つけたのはログイン失敗を抑制することだけですが、それは別のケースです。

答えて

0

これはアプリケーションの問題です。ユーザーがログインしてセッションを確立すると、そのセッションを保持し、そのたびにフローをCASにリダイレクトする必要がありません。ほとんどのcasクライアントはこれを自動的に行います。ユーザーがログアウトするか、アプリケーションセッションがリストになっているかタイムアウトした場合にのみ、リダイレクトされます。

+0

はい、そうですが、複数のタブが開いているブラウザを起動すると、すべてがCAS URL(ログインページ)になります。また、ユーザーのログイン時に他のタブはCASのURLに残ります。これにより、開いているすべてのタブごとにST生成が行われます。その他のケースは、ユーザーがアドレスバーからCAS URLをコピーする場合です。私たちのアプリケーションは、アプリケーションセッションのタイムアウト後にのみリダイレクトします。 – Worsik

関連する問題