그렇다면 왜 소셜 로그인을 사용하지 않나요?
1개의 좋아요
그러면 소셜 로그인은 왜 쓰지 않는가?
맞다, 그 방식이 많은 사람들을 커버하긴 한다. 하지만 로그인 제공업체에 대한 신뢰 부족 때문에 소셜 로그인을 사용하지 않는 사람들, 즉 나 같은 사람들이 점점 늘고 있다. 주요 제공업체들은 이 세상에서 가장 신뢰하기 어려운 기업들 중 일부다.
그리고 소셜 로그인은 아직 아무것도 모르는 커뮤니티에 가입하고 싶지 않은 사람들의 문제를 해결해주지 않는다. 원래 예로 든 대로, 나는 매우 구체적인 정보를 찾다가 구글을 통해 이 커뮤니티에 왔다. 아직 정보의 출처가 된 이 커뮤니티의 일원이 되고 싶은 어떤 관심도 없다. 가장 적은 노력을 들여 관계를 유지할 수 있는 방법을 제공하면, 커뮤니티가 가치를 보여주고 그 사람을 끌어들이는 기회를 가질 수 있다.
소셜 로그인은 기술적 장벽을 해결하는 방법이지, 심리적 장벽을 해결하는 방법은 아니다.
3개의 좋아요
그런데 모든 이메일 목록 서비스는 그렇게 작동합니다.
사용자가 입력한 이메일이 소셜 로그인에서 가져온 이메일과 동일하고, 소셜 로그인을 통해 인증할 때 공개 데이터(이미 공개된 것) 외에 요청되는 권한이 이메일 주소뿐이라면, 저는 소셜 로그인에 문제가 없다고 생각합니다.
예를 들어, 저는 보통 구글이나 GitHub로 인증을 하는데, 권한 요청이 뜨면 이메일만 요청되는지 확인합니다. 이 경우 이메일 주소를 직접 입력해야 하는 것(이 경우 이메일 인증도 해야 할 수 있음)보다 훨씬 편리하다고 생각합니다. 소셜 로그인은 클릭 1~2번으로 끝납니다.
사실 이메일을 직접 입력하는 것보다 소셜 로그인을 통해 뉴스레터(또는 유사한 서비스)에 구독할 가능성이 훨씬 더 높습니다. 물론 이는 제 개인적인 경우에 해당합니다.
내 답변에 다시 답을 남깁니다.
플러그인 디렉터리에서 비밀번호 없는 가입 옵션을 찾지 못했습니다. 대신 @codinghorror 님이 이 아이디어에 대한 몇 가지 반론을 제기한 이 토픽을 찾았습니다: Why is password still required at signup? 저는 그 의견에 동의하지 않지만, 이 아이디어에 대한 논의는 거기서 끝난 것 같습니다.
이제 제 Ruby 책을 다시 꺼내야 할지, 아니면 Marketplace 채널에 질문을 올려야 할지 결정할 때인 것 같습니다.
기존 API 엔드포인트를 확인해 보았습니다. 위에서 설명한 내용을 구현하려면 다음 두 엔드포인트의 기능을 결합한 플러그인이 필요합니다:
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", // 이제 선택 사항
"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인 경우 DB에 알림 항목 추가
또한 환영 이메일에 자신의 username, name, password를 설정하는 방법에 대한 설명을 추가해야 합니다. 이는 대부분 https://example.com/u/{username}/preferences/account 페이지에 이미 포함되어 있어 간단합니다. 단순히 한 단락만 삽입하면 됩니다.
물론 최소한 다음을 포함하는 UI 컴포넌트가 필요합니다:
- 이메일 입력 필드
- ‘이 주제 관찰’ 체크박스
- 제출 버튼
GDPR을 위해 '관찰’이 정확히 무엇을 의미하는지, 어떤 이메일을 받게 되는지 등에 대한 문서 페이지 링크를 추가하는 것도 좋은 아이디어입니다.
3개의 좋아요
이메일로 주제 생성을 허용하면 “staged”(단계적) 사용자를 생성하는 코드가 이미 존재합니다. 이러한 사용자는 랜덤한 사용자 이름을 가지며 각각 이메일 주소와 연결됩니다. 로그인하여 해당 이메일 주소를 인증하면 계정을 “claim”(인수)할 수 있습니다.
참고
이 기능을 기반으로 구축하는 것이 도움이 될까요?
3개의 좋아요
힌트 주셔서 감사합니다. 실제로 완벽해 보입니다.
이메일 수신 시 스테이징된 사용자를 생성하는 코드를 직접 호출할 수 있는지 코드를 살펴볼게요.
1개의 좋아요
네, 제 원래 생각도 그랬어요. 하지만 Active 속성이 가장 유용하지는 않을 수도 있겠네요.
완전한 User는 staged = false, active = true 상태이므로, 이 둘은 서로 다른 속성입니다(나중에 꼭 기억하기!)
유망한 제안이네요 @mattdm … 관련 작업을 상당히 줄일 수 있을 것 같습니다!
3개의 좋아요
코드를 꼼꼼히 살펴봤습니다. 아래처럼 하면 이메일만으로도 사용자가 답변을 게시할 수 있을 것 같습니다(경고: 아직 테스트해 보지 않아 작동하지 않을 가능성이 높음). 여러분의 의견이 있다면 알려주시면 감사하겠습니다.
특히 이렇게 스테이징(staged) 사용자를 생성하는 것이 최선의 방법인지 확신이 서지 않습니다. 스테이징 사용자를 명시적으로 생성하는 메서드를 아직 찾지 못했기 때문입니다.
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
4개의 좋아요
이 대화가 실제로 Staged Users를 활용하는 플러그인이나 발견된 프로세스로 이어진 적이 있나요?
2개의 좋아요