Entonces, ¿por qué no usar inicios de sesión sociales?
1 me gusta
Entonces, ¿por qué no usar inicios de sesión sociales?
Es cierto, eso cubre a mucha gente. Pero hay un número creciente de personas como yo que no usan el inicio de sesión social por falta de confianza en los proveedores de inicio de sesión. Los principales proveedores son algunas de las empresas menos confiables del planeta.
Y el inicio de sesión social no aborda el problema de que las personas simplemente no quieran convertirse en miembros de una comunidad sobre la que aún no saben nada. Volviendo a mi ejemplo original, llegué a esta comunidad a través de Google buscando información muy específica. Todavía no tengo ningún interés en ser parte de la comunidad que generó la información. Mantenerse en contacto a través del método de menor esfuerzo disponible le da a la comunidad la oportunidad de mostrar valor y atraer a esa persona.
El inicio de sesión social es una solución a la barrera técnica, no a la barrera psicológica.
3 Me gusta
Y sin embargo, todas las listas de correo funcionan de esa manera.
Si el correo electrónico que introduce el usuario es el mismo que el del inicio de sesión social, y considerando que el permiso solicitado al autenticarse a través del inicio de sesión social, aparte de los datos públicos (que ya son públicos), es la dirección de correo electrónico, entonces no veo ningún problema con el inicio de sesión social.
Por ejemplo, normalmente me autentico con Google o GitHub, y cuando se solicita el permiso, solo me aseguro de que se solicite solo el correo electrónico. En este caso, lo considero mucho más conveniente que introducir la dirección de correo electrónico, porque no tengo que escribirla (y con el inicio de sesión por correo electrónico, posiblemente también tenga que validar el correo electrónico). Con el inicio de sesión social, solo son 1 o 2 clics.
De hecho, es mucho más probable que me suscriba a un boletín (o cosas similares) a través de un inicio de sesión social que introduciendo el correo electrónico. Por supuesto, este es mi caso particular.
Respondiendo a mi propia respuesta.
No se me ocurrió ninguna opción de registro sin contraseña en el directorio de plugins. Encontré este tema donde @codinghorror tiene algunas objeciones a la idea: Why is password still required at signup? No estoy de acuerdo con él, pero parece que ahí terminó la discusión sobre esta idea.
Parece que es hora de desempolvar mi libro de Ruby o publicar en Marketplace.
He revisado los puntos finales de la API existentes. Parece que para lograr lo que he expuesto anteriormente, necesitaría un complemento que combine la funcionalidad de estos dos puntos finales:
POST /users.json
Solicitud:
{
"name": "string",
"email": "string",
"password": "string",
"username": "string",
"active": true,
"approved": true,
"user_fields[1]": true
}
POST /t/{id}/notifications.json
Solicitud:
{
"notification_level": "0"
}
en:
POST /plugin-name/users.json
Solicitud:
{
"email": "string",
"name": "string", // ahora opcional
"password": "string", // ahora opcional
"username": "string", // ahora opcional
"active": true,
"approved": true,
"user_fields[1]": true,
"notifications": [ // nueva propiedad
{
"topic_id": "some-topic-id",
"notification_level": "0"
}
]
}
Esta nueva lógica se agregaría:
- si el nombre es nulo, se generará uno automáticamente
- si el nombre de usuario es nulo, se generará uno automáticamente. Posiblemente se establecerá como un uuid
- si la contraseña es nula, se establecerá como un uuid de tipo 4 o simplemente una cadena aleatoria
- si len(notifications) > 0, se agregará una entrada de notificación a la base de datos
Además, se agregará información sobre cómo configurar su propio nombre de usuario, nombre y contraseña en el correo electrónico de bienvenida. Esto es fácil porque la mayor parte está en https://example.com/u/{username}/preferences/account. Esto podría ser solo un nuevo párrafo que se inserta.
Luego, por supuesto, necesitaría un componente de interfaz de usuario que como mínimo tenga:
- un campo de correo electrónico
- una casilla de verificación ‘Seguir este tema’
- un botón de envío
Para fines de GDPR, sería una buena idea agregar también un enlace a una página de documentación sobre qué significa exactamente ‘Seguir’, qué correos electrónicos recibirán, etc.
3 Me gusta
Ya existe código para crear usuarios “staged” si permites que se creen temas por correo electrónico. Estos tienen un nombre de usuario aleatorio y cada uno está asociado a una dirección de correo electrónico. Puedes “reclamar” la cuenta iniciando sesión y validando esa dirección de correo electrónico.
Ver
¿Quizás construir sobre esto podría ayudar?
3 Me gusta
Gracias por la indicación. De hecho, parece perfecto.
Investigaré el código y veré si puedo llamar directamente al código que crea el usuario provisional al recibir el correo electrónico.
1 me gusta
Sí, ese fue mi proceso de pensamiento original, pero Active podría no ser la propiedad más útil.
Un usuario completo está staged = false, active = true, por lo que estos son atributos diferentes (¡nota para mí mismo!)
Prometedora sugerencia @mattdm … ¡podría reducir significativamente el trabajo involucrado!
3 Me gusta
He pasado un tiempo de calidad revisando el código. Creo que algo como esto (advertencia: es muy probable que no funcione ya que aún no lo he probado) funcionaría para permitir al usuario publicar una respuesta solo con un correo electrónico. Agradecería cualquier comentario que tengas.
No estoy seguro especialmente si esta es la mejor manera de crear un usuario provisional. Sin embargo, no he encontrado ningún método que cree específicamente usuarios provisionales.
class SomePluginController < ApplicationController
# Asegúrate de que haya un usuario provisional en la base de datos
def ensure_user
# Comprueba si existe un usuario provisional
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# Crea un usuario provisional manualmente
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# Observa un tema como un usuario provisional
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
# Responde a un tema como un usuario provisional
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
3 Me gusta
¿Alguna vez esta conversación se materializó en un plugin o en un proceso descubierto que utilizara usuarios en etapas?
1 me gusta