プライベート登録、または手動承認が必要な登録を許可する方法を探しています。後者はここで説明されている戦略を使用して実行できますが、プロセスを簡素化するためにパスワード リセット モジュールを何らかの方法で利用できれば、前者の方法がより便利になると思います (1 回限りのトークンを使用して電子メールを送信しますが、アカウント作成の目的）。誰かがこのようなことを試みましたか、または既存のコンポーネントをより有効に活用するためのより良い戦略を考案しましたか?
質問する
323 次
2 に答える
2
私は、他の目的を達成するために他の目的のために設計されたフレームワークの機能を使用することをあまり好まないことを認めなければなりません。
アプリへの招待が必要なプライベートサインアップが必要な場合、私が通常行うことは、ユーザーの作成/登録をアプリケーション内に配置することです。結局のところ、Devise はUserモデル上の認証メカニズムにすぎません。
たとえば、私の現在のアプリでは、既存のユーザーが友達を招待するための明示的な方法がアプリ内にあります。招待するユーザーには、メール アドレスと、ユーザーが登録を完了したかどうかを通知するフィールドを使用して、新しいユーザーのエントリをユーザー テーブルに作成するフォームがあります。データベースにも保存される小さなトークンを作成します (SecureRandom.hex(8)このようなトークンを作成する良い方法です)。システムは新しい人に (トークンを含む URL で) サインアップする場所を知らせる電子メールを送信します。サインアップは、パスワードと追加フィールドを設定する単なるフォームです。
これはすべて、Rails の本当の魔法ではありません。2 つのコントローラー アクション、2 つのビュー、および 1 つのメーラーですべてが実現され、Devise が提供する、または提供しない API によって制約されることはありません。
Devise が招待トークンをまだ引き換えていないユーザーを認証しないようにするだけで済みましたが、それだけです。
サインアップ ビューを作成する必要がないことは確かに便利ですが、特に部分的な情報 (私の場合、招待するユーザーは、新しいユーザーに関するいくつかの情報を既に入力する必要があります) を扱っている場合は、新しいユーザーによってのみ補完されます。何でもできる通常のフォームがあると便利です。
まさにこれを行うために Devise を拡張する Gem を誰かが作成しない限り、私はこのアプローチに固執すると思います。
于 2013-01-03T09:44:53.377 に答える
0
3 番目の戦略があったことがわかりました。単純に新しいアカウントをロックし (ロック可能、before_create フィルター)、手動でロック解除機能を提供することができました。
于 2013-01-05T09:16:41.610 に答える