활성화하기 전에, 이 기능은 enable_local_logins와 enable_local_logins_via_email이 모두 true여야만 켤 수 있으므로 이 두 설정이 true인지 확인하세요. DiscourseConnect(enable_discourse_connect)를 사용 중인 경우 이 기능을 활성화할 수 없습니다.
변경 사항이 활성화되면 코드 로그인 경로가 자동으로 나타납니다.
신규 계정을 위한 랜덤 사용자 이름
인식 가능한 사용자 이름이 포함된 이메일 없이 가입하는 신규 회원에게는 이제 user1과 같은 일반적인 플레이스홀더 대신 "QuietFalcon42"와 같은 친근하게 생성된 이름이 부여됩니다. 계정 준비 단계에서 제안된 이름이 미리 입력되며, 새로운 이름을 생성하기 위한 주사위 버튼이 포함됩니다.
제안 이름 뒤에 있는 단어 목록은 random_username_adjectives 및 random_username_nouns 사이트 설정을 통해 구성할 수 있으므로, 커뮤니티는 자신의 톤이나 언어에 맞게 조정할 수 있습니다. 이전의 번호 기반 폴백을 유지하려면 enable_random_usernames를 비활성화하여 옵트아웃할 수 있습니다.
여러분의 생각은?
이제 여러분의 차례입니다: 이 새로운 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 무엇이 좋고 나쁜지, 무엇이 잘 작동하고 무엇이 개선될 수 있는지 알려주세요.
This new flow removes the current “generate email, type username, generate password, save” strategy that my password manager has pushed me into and forces you to type the email first before everything. I don’t have an issue with the email code thing (and in fact almost prefer it, especially if the code is included in the email subject) but I strongly oppose removing the other account data boxes. If I were a user with zero technical background I would also see myself not handing out my email to a box with no info like this because it isn’t a common design. Before this becomes a permanent thing, it’d be great if that was added back.
Email codes, AKA “magic links”, are decent, but nudging users towards passkeys makes the experience way, way better.
One of the biggest problems with email codes is that they don’t do what you’d want them to do in in-app browsers, including Gmail’s in-app browser.
Probably the most common problem people run into with magic links is they think they have logged into the site on their normal browser, but they’re actually logged in through an in-app browser. For example, someone might receive the login link to their email. They open up the Gmail app, click the “Sign in to 404 Media” button, and their phone loads the webpage. But this is loading the website in Gmail’s web browser, not your native Safari one.
Passkeys fix this issue.
To start, websites using magic links can make passkeys an optional, opt-in feature for the customers who have complained about how their magic links work today. To ensure it doesn’t cause any problems, as a sort of soft launch, they could make the feature 100% opt-in.
Slightly later on, once the people running the website are convinced that passkeys really help with the user experience issues around magic links, they can prompt users to add passkeys after signing in, once every 90 days or so, or whenever they sign-in using the cross-device sign-in feature of passkeys. The framing of such a prompt can be something like this for users on Apple devices: Want to avoid having to check your email next time? Set up a passkey to use Face ID or Touch ID to sign in quickly and securely.
I like this approach a lot! However, it bothers me a bit that the display name cannot be changed before the registration is finished. I think it would be great to add an option to change it during the process.
In my community, I have disabled the Prioritize username in UX site setting, which means the Full Name/Display Name is prioritized across the UI. Because of this, automatically assigned names like “user21” look pretty bad on the front-end if the user doesn’t have an immediate option to customize it.
This new flow does not send a magic link. It only sends the code. The user stays on the same page, and copy/pastes the code from their email to the signup form. So this new approach does help with in-app browsers (it’s one of the main advantages of the change).
This is certainly something we would like to do next, in the password step of the signup. Apps and websites have ramped up their support of passkeys, I keep seeing the passkeys nudge in many contexts, so it makes sense to add to Discourse as well. (Critical mass of support is very helpful in this switch from passwords to passkeys.)
My only issue with this feature is that it removes the name and username fields from my signup page. Is this intentional? I don’t want to force users to spelunk around in settings right after signup just to set a username that isn’t “user63”.
I agree. Those generic usernames make interacting with users more confusing. Since users by default only have 3 days to update the names, I expect that frequently they will notice after that time has passed, so staff needs to take care of renaming them.
I really enjoyed that Offering blank username suggestions rather than ‘UserN’ at signup prevented that from happening for example here on meta. The last userXXX was created on January 7th before that fix was merged. Then there was no new userXXX until this feature was enabled, and since then there are 12 new ones.
이것은 좀 이상한 인용입니다. DomMcD가 저를 인용한 것처럼 보이지만, 사실은 그렇지 않습니다.
저는 해당 단계를 테스트해 본 적이 없습니다. 저는 Meta에서 신규 사용자와 관련된 제 관찰 사항에 대해 언급하고 있을 뿐입니다. 가입 시 특정 필드를 보느냐의 여부는 중요하지 않습니다. 다른 사람들이 그 필드를 어떻게 다루는지에 대해 제가 어떻게 대응해야 하는지가 중요하니까요.
또한 이름이 어떻게 처리되는지도 궁금합니다. 모든 사용자가 생성된 사용자명을 사용하는 것은 아닌 것 같지만, 이름이 userXXX로 설정된 사용자가 더 많다는 것을 알아차립니다.
사용자명을 변경해도 여전히 그런 이름이 부여되는 것 같습니다. 이로 인해 같은 숫자가 반복적으로 사용되다가, 해당 사용자명이 이미 사용 중이면 다음 숫자로 다시 시작되는 현상이 발생한다고 합니다.
변경된 사항
커뮤니티에서 1회용 로그인 코드 활성화하기
활성화하기 전에, 이 기능은 
신규 계정을 위한 랜덤 사용자 이름
여러분의 생각은?
