모든 Discourse 사이트, 호스팅 및 자체 호스팅 사이트를 포함하여 Discourse ID를 이제 활성화할 수 있게 되어 기쁩니다!
Discourse ID는 참여하는 Discourse 사이트 전반에서 더 빠른 로그인 경험을 제공하여, 방문하는 각 Discourse마다 별도의 로그인을 생성할 필요가 없으며, 클릭 한 번으로 참여하는 모든 Discourse 사이트에 가입할 수 있습니다. 또한 Discourse 관리자가 설정이나 구성 없이 소셜 로그인을 지원하는 간소화된 로그인 경험을 제공할 수 있게 해줍니다.
There’s a UX thinko: I’m on Safari on a Mac, and when I try to login, here on Meta, using my shiny new Discourse ID: I successfully pass the authentication on Discourse ID, and then it redirects me . . . to the Discourse App. I do have that app installed, but it should continue, in Safari, to redirect me to Meta. (And of course Meta does point out, at the top of my Safari window, that I can open Meta in the App.)
Oh, sorry about that, we have an over-eager Apple App Site Association file on meta at the moment. I made an update, but sadly it will take up to 24 hours for the Apple CDN to work. I’ll check then to make sure it is fixed.
Just can’t get it work. Here, I mean. Connecting fails all the time. It doesn’t accept password and google/facebook tries to create totally new account. This is actually the very first time ever I couldn’t use login and/or create passkey.
Can we have tradition SSO (Google, Discord, etc) in addition to Discourse ID? We are considering implementing this, but dont want to force users to migrate their accounts
Yes! You can choose to have both types of options enabled or ask users to switch over to ID and phase out the old login methods (as the migration aspect is optional).
The only drawback I can think of is that you’ll have to make sure those login configurations are up to date and working correctly, and ensure that users are not too confused by the various login options presented as ID ships with them out of the box.
The issue here or might be is that users must know they have to create an account to id.discourse. That isn’t something new and that is the way how SSO works. But I don’t know how to explain to users why they should do that, when there is another SSO options.
Unless CDCK has plans to monopolize registrations and stop to support Google etc. So, I don’t totally understand meaning of that.
Do you intend to enable this authentication method by default in the future? The usefulness seems limited if it is not. I wouldn’t be surprised if only a few sites enable it, just because admins in general don’t know what it is or are not aware of it.
Yes, for self-hosters we are working on including Discourse ID as an easy option for the initial setup. We’d like to see if it can let people start a new instance without the dreaded email step, because with Discourse ID, users don’t need email for setting up their first account. They will need email eventually, but postponing that arduous process even a little bit is useful.
We are also looking to enabling Discourse ID by default on signups in our hosting.
I’ve been looking forward to Discourse ID being ready, and it works great! I especially like that it takes alternate email addresses into account, so I can use the same Discourse ID for sites that use different email address as their primary ones.
There are already so many Discourse sites in the wild that I’d be happy if the setting was enabled automatically via a site update as long as admins notified. Or perhaps better, a choice popup in the backend after the update that let us choose if we want to enable or disable this feature.