登録不要でメールアドレスを使ってトピックをウォッチする

特徴
21

では、ソーシャルログインを使用してみてはいかがでしょうか？

「いいね！」 1
22

「では、なぜソーシャルログインを使わないのですか？」

確かに、それは多くの人々をカバーします。しかし、ログインプロバイダーへの不信感からソーシャルログインを使用しない人も増えています。主要なプロバイダーは、世界で最も信頼されていない企業の一部です。

また、ソーシャルログインは、まだ何も知らないコミュニティのメンバーになりたくないという人々の問題を解決しません。元の例に戻ると、私は非常に具体的な情報を求めてGoogle経由でこのコミュニティに来ました。私はまだ、その情報を作成したコミュニティの一部であることに全く興味がありません。利用可能な最も低労力の方法で連絡を取り続けることで、コミュニティはその価値を示し、その人をコミュニティに取り込む機会を得ることができます。

ソーシャルログインは、技術的な障壁に対する解決策であり、心理的な障壁に対する解決策ではありません。

「いいね！」 3
23

それにもかかわらず、すべてのメーリングリストはそのように機能しています。

24

ユーザーが入力したメールアドレスがソーシャルログインのメールアドレスと同じで、ソーシャルログインで認証する際に要求される権限（公開データ以外で、すでに公開されているもの）がメールアドレスである場合、ソーシャルログインに問題はないと思います。

例えば、私は通常GoogleやGitHubで認証しますが、権限を求められた際には、メールアドレスのみが要求されていることを確認します。この場合、メールアドレスを入力するよりもはるかに便利です。なぜなら、入力する必要がないからです（メールログインでは、メールアドレスの検証も必要になる可能性があります）。ソーシャルログインなら、クリックは1〜2回で済みます。

実際には、メールアドレスを入力するよりも、ソーシャルログイン経由でニュースレター（またはそれに類するもの）に登録する可能性の方がはるかに高いです。もちろん、これは私の個人的なケースです。

25

自分の投稿に返信します。

プラグインディレクトリでパスワードなしの登録オプションを見つけられませんでした。@codinghorror がこのアイデアに反対しているトピックを見つけました: Why is password still required at signup? 私はそれに同意しませんが、このアイデアについての議論はそこで終わったようです。

Rubyの本を引っ張り出すか、Marketplace に投稿するかのどちらかの時期のようです。

26

既存のAPIエンドポイントを確認しました。上記で概説したことを達成するには、これら2つのエンドポイントの機能を組み合わせたプラグインが必要になるようです。

POST /users.json
Request:
  {
    "name": "string",
    "email": "string",
    "password": "string",
    "username": "string",
    "active": true,
    "approved": true,
    "user_fields[1]": true
  }


POST /t/{id}/notifications.json
Request:
  {
    "notification_level": "0"
  }

を以下のようにします。

POST /plugin-name/users.json
Request:
  {
    "email": "string",
    "name": "string",       // now optional
    "password": "string",   // now optional
    "username": "string",   // now optional
    "active": true,
    "approved": true,
    "user_fields[1]": true,
    "notifications": [      // new property
      {
        "topic_id": "some-topic-id",
        "notification_level": "0"
      }
    ]
  }

この新しいロジックが追加されます。

  • nameがnullの場合、自動生成します。
  • usernameがnullの場合、自動生成します。おそらくuuidに設定するだけです。
  • passwordがnullの場合、type 4 uuidまたはランダムな文字列に設定します。
  • len(notifications) > 0の場合、データベースに通知エントリを追加します。

さらに、ウェルカムメールに、独自のユーザー名、名前、パスワードの設定方法に関する説明を追加する必要があります。これは、ほとんどがhttps://example.com/u/{username}/preferences/accountにあるため簡単です。これは新しい段落として挿入されるだけです。

もちろん、少なくとも以下を含むUIコンポーネントが必要になります。

  • メールフィールド
  • 「このトピックをウォッチする」チェックボックス
  • 送信ボタン

GDPRの目的上、「ウォッチ」の意味、受信するメールなどについて正確に説明したドキュメントページへのリンクを追加することも良いでしょう。

「いいね！」 3
28

メールでトピックを作成できるようにすると、「ステージング済み」ユーザーを作成するためのコードが既に存在します。これらのユーザーにはランダムなユーザー名が付けられ、それぞれがメールアドレスに関連付けられます。ログインしてそのメールアドレスを検証することで、アカウントを「請求」できます。

以下を参照してください。

これを基盤にすると役立つかもしれません。

「いいね！」 3
29

ポインターありがとうございます。それは完璧に見えます。

コードを調べて、メール受信時にステージング済みユーザーを作成するコードを直接呼び出せるかどうかを確認します。

「いいね！」 1
30

はい、それが私の最初の考え方でしたが、Active は最も役立つプロパティではないかもしれません。

完全なユーザーは staged = false、active = true なので、これらは異なる属性です（自分へのメモ！）。

@mattdm さん、有望な提案です…involved work を大幅に削減できる可能性があります！

「いいね！」 3
31

コードをじっくり調べてみました。ユーザーがメールだけで返信できるようにするには、次のようなもの（注意：まだ試していないので、おそらく動作しません）が機能すると思います。何かコメントがあれば幸いです。

特に、ステージングされたユーザーを作成する最良の方法かどうかはわかりません。ステージングされたユーザーを具体的に作成する方法は見つかりませんでした。

class SomePluginController < ApplicationController

  # データベースにステージングされたユーザーがいることを確認する
  def ensure_user

    # ステージングされたユーザーが存在するか確認する
    user = User.where(staged: true).with_email(params[:email].strip.downcase).first

    # ステージングされたユーザーを手動で作成する
    if !user
      user = User.new
      user.staged = true
      user.email = params[:email]
      user.active = false
      user.save!
    end
    
    user
  end

  # ステージングされたユーザーとしてトピックを監視する
  def staged_watch

    user = ensure_user

    topic = Topic.find(params[:topic_id].to_i)
    TopicUser.change(user, topic.id, notification_level: params[:notification_level].to_i)

  end

  # ステージングされたユーザーとしてトピックに返信する
  def staged_reply
 
    user = ensure_user

    manager = NewPostManager.new(user,
                             raw: params[:body],
                             topic_id: params[:topic_id])
    result = manager.perform

  end

end
「いいね！」 3
32

この会話は、Staged Users を利用したプラグインや発見されたプロセスに発展しましたか？

「いいね！」 1