התחברות בדף משלך

רוב האפליקציות שולחות אנשים ל-Lobby של הסביבה כדי להתחבר. אם עדיף לך להשאיר אותם בדף שלך, <SignIn /> מ-@usher/react מחבר אותם בדיוק שם, ואז מסיים עם OpenID Connect בדיוק כמו קודם: השרת שלך עדיין מקבל את האסימונים שלו מ-Usher, ואף סיסמה או אסימון לא עוברים דרך הדף שלך.

אישור המקור (origin) של האפליקציה

ב-Usher Console, פותחים את הסביבה ועוברים אל התחברות ← התחברות מוטמעת, ומוסיפים את המקור של האפליקציה, כמו https://app.example.com. רק מקורות שברשימה רשאים להשתמש ב-Frontend API של הסביבה, ורק לצורך התחברות.

הוספת הרכיב

TSX

import { SignIn } from '@usher/react'

export function SignInPage() {
  return <SignIn frontendApi="https://login.example.com" returnTo="/dashboard" />
}

הרכיב יושב בתוך ה-UsherProvider ש-@usher/nextjs כבר משתמש בו. frontendApi הוא המנפיק של הסביבה שלך.

מה קורה

קודם כתובת הדוא״ל, אחריה סיסמה או קוד בדוא״ל, ואחר כך השלב השני אם יש לאדם כזה. התחברות דרך רשת חברתית ו"המשך עם Usher" עוברות לספק וחוזרות לאפליקציה שלך.
ואז OpenID Connect. אחרי ההתחברות בסביבה, הרכיב שולח את הדפדפן ל-/auth/sign-in של האפליקציה שלך, שעובר ישר דרך Usher וחוזר עם קוד. בפעם הראשונה, Usher מבקש מהאדם לאשר את האפליקציה שלך.
ההגנה מפני בוטים פועלת כמו ב-Lobby: כש-Usher מבקש הוכחת עבודה, הרכיב מבצע אותה.
כל השאר (מפתחות גישה, התחברות ארגונית, יצירת חשבון) הוא קישור ל-Lobby שלך.

דומיין משלך בסביבת ייצור

הרכיב שומר את הסשן של Usher בקובצי ה-Cookie של הסביבה. בסביבת ייצור הם חייבים להיות של צד ראשון: נותנים לסביבה דומיין משלך, באותו אתר כמו האפליקציה (login.example.com עבור app.example.com). בסביבת פיתוח, סביבה שמאפשרת הטמעה שולחת את קובצי ה-Cookie שלה בין אתרים, ו-Chrome מקבל את זה. בדפדפן שלא שומר אותם, הרכיב מעביר את האדם ל-Lobby במקום.