5

私は自分のplay/scalaアプリにSecureSocialを統合し始めましたが、異なるビュー間で行われるすべてのリダイレクトが本当に好きではありません。

例-デフォルトのログインページからログインしてみてください。間違ったパスを入力すると、同じログインフォームで別のページ（URL）にリダイレクトされます。唯一の違いは、エラーメッセージがあることです...

メインページの隅に、ajaxを使用してデータを送信する簡単なログインフォーム（ユーザー/パスワードプロバイダー）が必要です。このデータはサーバーで検証され、エラーメッセージを表示するかウィンドウを変更するための応答が行われます。位置。このフォームの横に、fb / twitterなどの他のプロバイダーを使用するオプションを追加するより高度なログインページに移動するためのリンクを配置します。ただし、そのページから、ajaxを使用して詳細を送信し、応答を取得したいと思います。 。

SecureSocialソースを参照しようとしましたが、そこで少し迷子になりました。

SecureSocialのビューを使用せずに、SecureSocialの使用方法を教えてもらえますか？

注：ビューのカスタマイズには興味がありません。CSS/デザインの問題だけでなく、ログインの詳細をAjaxlyで処理し、通常のフォーム送信とそれに続くリダイレ​​クトでは処理しません...

4

1 に答える 1

2

SecureSocialコードをいじくり回した後、私はそれがどのように動作するかをよりよく理解しました。

play.pluginsファイルにリストしたプロバイダーのいずれかを個別に使用して、独自のログイン/認証コードからユーザーの情報を認証できます。プロバイダーが必要とする適切なパラメーターを送信するようにしてください。

SecureSocialのProviderControllerクラスが、パラメーターに基づいて使用するプロバイダーを動的に決定する方法が気に入りました。しかし、私はそれが行った応答が気に入らなかった-リダイレクト..私はいくつかのデータでajaxリクエストに応答し、クライアント側のjsにそれを処理させたかった。

これが私の解決策です：

ほとんどすべてのProviderControllerコードを自分のAuth.scalaファイル（コントローラー）にコピーします。「caseex、case _」に関連するリダイレクトを変更し、ユーザーに関連するSecureSocialセッションキーを追加するため、認証が成功したときにリダイレクトを維持しました。ルートファイルからすべてのSecureSocial関連ルートを削除しました。ログインタイプ（userpass / google / fb / etc ...）を使用して追加の非表示フィールドを配置し、ログインajax投稿を構成して、これを投稿と一緒にAuthコントローラーに送信します。

さらに詳しい情報が必要な場合は、ここにコメントしてください。回答を編集します。

于 2013-01-21T09:12:44.267 に答える