Then why not use Social logins?
1 Like
Then why not use Social logins?
True, that covers a lot of people. But there are a growing number of people like me that don’t use social login out of lack of trust for the login providers. The main providers are some of the least trusted companies on the planet.
And social login doesn’t address the issue of people simply not wanting to become a member of a community that they do not yet know anything about. Going back to my original example, I came to this community via Google looking for very specific information. I do not yet have any interest in being part of the community that generated the information. Keeping in touch via the most low-effort method available gives the community the chance to show value and bring that person into the fold.
Social login is a solution to the technical barrier, not the psychological barrier.
3 Likes
And yet all emaillists work that way.
If the email the user enters is the same as the email from the social login, and considering that the permission requested when authenticating via social login, other than public data (that is already public), is the email address, than I don’t see a problem with the social login.
For example, I normally authenticate with google or github, and when the permission is asked I only make sure that only the email is requested. In this case I consider it much more convenient than entering the email address, because I don’t have to write it (and with email login I will possibly also have to validate the email). With social login it’s only 1 or 2 clicks.
Actually, it’s much more likely that I will subscribe to a newsletter (or similar stuff) via a social login than entering the email. Of course, this is my specific case.
Replying to my own response.
I didn’t come up with any passwordless registration options in the plugin directory. I did find this topic where @codinghorror some objections to the idea: Why is password still required at signup? I don’t agree with them, but that seems to have been the end of discussion on this idea.
It looks like it’s time to either dust off my Ruby book or post on marketplace
I’ve had a look at the existing API endpoints. It looks like in order to acomplish what I’ve laid out above, I’d need a plugin that combines functionality from these two endpoints:
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"
}
into:
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"
}
]
}
This new logic would be added:
- if name is null, auto-generate one
- if username is null, auto-generate one. Possibly just set to a uuid
- if password is null, set to a type 4 uuid or just a random string
- if len(notifications) > 0, add a notification entry to the db
Additionally some language about how to set your own username, name, and password should be added to the welcome email. This is easy becase most of it is in https://example.com/u/{username}/preferences/account. This could just be one new paragraph that gets inserted.
Then of course you’d need a UI component that at a minimum has:
- an email field
- a ‘Watch this topic’ checkbox
- a submit button
For GDPR purposes, it would be a good idea to also add a link to a page of documentation on exactly what ‘Watch’ means, what emails they will get, etc.
3 Likes
There is already code there to create “staged” users if you allow topics to be created by mail. These have a random username and are each associated with an email address. You can “claim” the account by logging in and validating that email address.
See
Maybe building on this would help?
3 Likes
Thanks for the pointer. That actually looks perfect.
I’ll dig into the code and see if I can directly call the code that creates the staged user upon email receipt.
1 Like
Yep that was my original thought process but Active may not be the most useful property.
A full User is staged = false, active = true, so these are different attributes (note to self!)
Promising suggestion @mattdm … might well cut down the work involved significantly!
3 Likes
I’ve spent some quality time digging through the code. I think something like this (warning: very likely not working as I haven’t tried it yet) would work to allow the user to post a reply with just an email. I’d appreciate any comments you have.
I’m especially not sure if this is the best way to create a staged user. I haven’t found any method that specifically creates staged users though.
class SomePluginController < ApplicationController
# Make sure there is a staged user in the db
def ensure_user
# See if staged user exists
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# Create a staged user manually
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# Watch topic as a staged user
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
# Reply to topic as a staged user
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
3 Likes
Did this conversation ever materialize into a plugin or a discovered process utilizing Staged Users?
1 Like