使用电子邮件地址关注主题，无需注册

功能
21

那为什么不使用社交登录呢？

1 个赞
22

那么为什么不使用社交登录呢？

确实，这能覆盖很多人。但也有越来越多像我一样的人，因为不信任登录提供商而选择不使用社交登录。主要的提供商是一些地球上最不可信的公司。

而且，社交登录也无法解决人们根本不想加入一个他们还不了解的社区的问题。回到我最初的例子，我是通过谷歌搜索特定信息来到这个社区的。我目前对成为这个社区的一员没有任何兴趣。通过最省力的方式保持联系，能让社区有机会展示其价值并吸引那个人加入。

社交登录是解决技术障碍的方案，而不是心理障碍的方案。

3 个赞
23

然而，所有的电子邮件列表都是这样工作的。

24

如果用户输入的电子邮件与社交登录的电子邮件相同，并且考虑到除公共数据（已公开）之外，在通过社交登录进行身份验证时请求的权限是电子邮件地址，那么我不认为社交登录存在问题。

例如，我通常使用 Google 或 GitHub 进行身份验证，当请求权限时，我只确保只请求电子邮件。在这种情况下，我认为这比输入电子邮件地址方便得多，因为我不必输入它（并且使用电子邮件登录我可能还需要验证电子邮件）。通过社交登录，只需单击 1 或 2 次即可完成。

实际上，我更可能通过社交登录订阅新闻通讯（或类似内容），而不是输入电子邮件。当然，这只是我的个例。

25

回复我自己的帖子。

我在插件目录中没有找到任何无密码注册选项。我确实找到了这个帖子，其中 @codinghorror 对这个想法提出了一些反对意见：Why is password still required at signup? 我不同意他的观点，但这似乎是关于这个想法的讨论的终点。

看起来是时候重新拿起我的 Ruby 书籍或者在 Marketplace 上发帖了。

26

我已经查看了现有的 API 端点。为了完成我上面概述的内容，我需要一个结合了这两个端点功能的插件：

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


POST /t/{id}/notifications.json
请求：
  {
    "notification_level": "0"
  }

合并为：

POST /plugin-name/users.json
请求：
  {
    "email": "string",
    "name": "string",       // 现在是可选的
    "password": "string",   // 现在是可选的
    "username": "string",   // 现在是可选的
    "active": true,
    "approved": true,
    "user_fields[1]": true,
    "notifications": [      // 新属性
      {
        "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 的建议很有前景……可能会大大减少所需的工作量！

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 个赞