okta signin widget
7.25.1
Das OKTA-Sign-In-Widget ist ein JavaScript-Widget, das ein vollständig vorgestellter und anpassbares Login-Erlebnis bietet, mit dem Benutzer in Web- und mobilen Anwendungen authentifiziert und registriert werden können.
Das Widget wird auf der Standard -Signin -Seite von OKTA verwendet, um eine OKTA -SSO -Sitzung zu starten und das Okta -Session -Cookie im Webbrowser festzulegen. Es kann auch einen OIDC -Fluss durchführen, um Ihre Web- oder mobilen Anwendungen einfach in die Okta -Plattform zu integrieren.
Eine benutzerdefinierte Signin-Seite mit Okta-veranstaltete Signin kann so konfiguriert werden, dass sie den Domainnamen und das Branding Ihres Unternehmens verwenden.
Das Widget kann auch direkt in die Web- oder Mobilanwendungen Ihres Unternehmens eingebettet werden, um eine nahtlose Benutzererfahrung zu erhalten.
Weitere Informationen zum Einstieg mit dem Anmeldewidget finden Sie im Nutzungshandbuch.
yarn linkDie Okta Identity Engine (OIE) ist ein Plattformdienst, mit dem Unternehmen flexiblere Zugriffserlebnisse aufbauen können, die auf ihre organisatorischen Anforderungen zugeschnitten sind. Das Okta-Anmelde-Widget unterstützt OIE in allen Nutzungsszenarien.
Hinweis : Sofern nicht anders angegeben, geht diese Readme davon aus, dass Sie Identity Engine verwenden. Informationen zur Verwendung des Widgets mit der klassischen Engine finden Sie in diesem Dokument
Das Anmelde-Widget ist in sich geschlossen und benötigt zur Laufzeit keine anderen Frameworks. Es kann jedoch bestimmte Funktionen geben, die Ihre App benötigt, z. B. Token -Speicher, Erneuerung oder Validierung, die das Widget nicht bereitstellt.
Diese SDKs sind vollständig mit dem Okta-Anmelde-Widget kompatibel und bieten Dienstprogramme, um die Okta-Authentifizierung von End-to-End in Ihre eigene Anwendung zu integrieren.
Komplette Beispielanwendungen zeigen die Verwendung des Okta-Anmelde-Widgets sowohl in Okta-veranstalteten als auch in eingebetteten Szenarien.
Es gibt verschiedene Möglichkeiten, das Okta-Anmelde-Widget zu verwenden:
OKTA bietet eine Standard-Anmeldeseite für Ihre Organisation, die bei der OKTA-URL Ihres Unternehmens gehostet wird.
OKTA unterstützt eine Option, um eine benutzerdefinierte Domain mit einer hoch anpassbaren Okta-veranstalteten Anmeldung zu erstellen.
Sie können das Widget direkt in Ihre Anwendung einbetten.
OKTA bietet eine Anmeldeseite, die bei der URL Ihres Unternehmens verfügbar ist und es dem Benutzer ermöglicht, den gesamten Autorisierungsfluss zu vervollständigen, eine SSO-Sitzung (Single-Sign-On) zu starten und das Okta-Cookie im Webbrowser festzulegen. Sie können diese Seite mit einem Hintergrundbild und einem Logo anpassen. Standardmäßig leitet die Anmeldung auf dieser Seite den Benutzer in das Okta -Benutzer -Dashboard weiter.
Die Standard-Anmeldeseite von Okta-veranstaltet kann auch einen Benutzer in einer OIDC-Anwendung authentifizieren. Ihre App kann zu einer Anmeldeseite umleiten, um den Authentifizierungsfluss durchzuführen. Danach leitet Okta den Benutzer wieder zum App-Rückruf um. OKTA bietet SDKs in vielen Sprachen zur Verfügung, um die Umleitungs -URL zu konstruieren und den Anmelderuf im Rahmen des gehosteten Flusses zu verarbeiten.
OKTA bietet mehrere vollständige Beispielanwendungen, die demonstrieren, wie der Okta -Hosted Flow verwendet wird.
Okta bietet auch eine gehostete Anmeldeseite, die so angepasst werden kann, dass sie unter einer benutzerdefinierten Domain verfügbar ist, die eine Subdomäne der obersten Domain Ihres Unternehmens ist. Obwohl die Seite von Okta gehostet wird, können Sie die Vorlage dieser Seite auf viele leistungsstarke Arten anpassen.
In Bezug auf Ihre App verhält sich das individuelle Widget genauso wie das Standard-Okta-veranstaltete Widget und Sie können denselben gehosteten Fluss verwenden.
Hinweis: Auf der Seite gibt es ein Konfigurationsobjekt, das alle erforderlichen Werte und aktivierten Funktionen enthält. Sie müssen dieses Objekt höchstwahrscheinlich nicht ändern. Wenn Sie feststellen, dass Sie diese Konfiguration ändern müssen, achten Sie darauf, dass Sie nicht überschreiben oder die erforderlichen Werte entfernen.
Für eine völlig nahtlose Erfahrung, die die höchste Anpassungsstufe ermöglicht, können Sie das Anmelde-Widget direkt in Ihre Anwendung einbetten. Dies ermöglicht die vollständige Verwendung der Konfiguration und API des Widgets.
Mithilfe eines eingebetteten Widgets können in vielen Fällen die Umleitung des hosteten Flusses die Roundtrips-Umleitung des gehosteten Flusses vermeiden. Siehe Showsignin.
Serverseitige Webanwendungen empfangen die Server-Seite von OAuth-Tokens, sodass sie einen Umleitungsrückruf verarbeiten müssen . Diese Apps sollten showSigninandRect verwenden.
Sie können das Anmelde-Widget in Ihre App einbetten, indem Sie entweder ein Skript-Tag aufnehmen, das das Widget aus dem Okta-CDN zieht oder das NPM-Modul in Ihre App bündelt.
Das Laden unserer Vermögenswerte direkt von der CDN ist eine gute Wahl, wenn Sie eine einfache Möglichkeit haben möchten, mit dem Widget zu beginnen. Sie haben noch keinen vorhandenen Build -Prozess, der NPM oder Garn für externe Abhängigkeiten oder einen anderen Grund nutzt, bei dem Sie nicht anziehen. Ich möchte das Anmelde-Widget in Ihre Anwendung bündeln.
Das Standard-Bundle ( okta-sign-in.min.js ) beinhaltet die Unterstützung sowohl für den klassischen Motor als auch für den Identitätsmotor. Es enthält auch eine Polyfill, um die Kompatibilität mit älteren Browsern wie IE11 zu gewährleisten. Wenn Ihre Anwendung IE11 nicht unterstützen muss, können Sie stattdessen das no-polyfill Bundle einfügen, um die Ladezeit für Erstnutzer zu verkürzen. Das eigenständige polyfill -Bündel kann auf den Seiten bedingt enthalten sein, um ältere Browser nur bei Bedarf zu unterstützen.
Wenn Ihre Organisation auf Identity Engine aktualisiert hat, kann das kleinere oie -Bundle verwendet werden.
| Bündeln | Dateiname | Ca. Größe | Klassiker Motor | Identitätsmotor | Polyfill | Notizen |
|---|---|---|---|---|---|---|
| Standard | okta-sign-in.min.js | 1,7 MB | ✅ | ✅ | ✅ | Standard -Bundle, das alles enthält |
| No-PolyFill | okta-sign-in.no-polyfill.min.js | 1,7 MB | ✅ | ✅ | Standardbündel ohne Polyfill | |
| Oie | Okta-sign-in.oie.min.js | 1,3 MB | ✅ | Kleineres Bundle für OIE -fähige Orgs | ||
| Klassiker | okta-sign-in.classic.min.js | 1,1 MB | ✅ | Nur kleineres Bündel für klassischen Motor | ||
| Polyfill | okta-sign-in.polyfill.min.js | 108 kb | ✅ | Eigenständiges Polyfill -Bündel. Kann zusammen mit einem Widget -Bundle verwendet werden, das die Polyfill nicht enthält. |
Um das Anmelde-Widget über CDN einzubetten, geben Sie Links zu den JS- und CSS-Dateien in Ihr HTML auf:
<!-- Latest CDN production Javascript and CSS -->
< script src =" https://global.oktacdn.com/okta-signin-widget/7.25.1/js/okta-sign-in.min.js " type =" text/javascript " integrity =" sha384-8QHSy1n8imbyR7imair5z4njOEYiZZk5gqBOJYbbUN3W6HQwW3PZ9lYQiybespeW " crossorigin =" anonymous " > </ script >
< link href =" https://global.oktacdn.com/okta-signin-widget/7.25.1/css/okta-sign-in.min.css " type =" text/css " rel =" stylesheet " integrity =" sha384-63aTBe2wMqzMRsDHNmlF/FreSWmf3p08BhUDoPlzVf3d+stbkfWtqmdyJ4He5m3m " crossorigin =" anonymous " />Hinweis: Die CDN -URLs enthalten eine Versionsnummer. Diese Nummer sollte sowohl für das JavaScript als auch für die CSS -Datei gleich sein und eine Version auf der Seite "Releases" übereinstimmen. Wir empfehlen die neueste Widget -Version.
Bei Verwendung eines der Bündel ohne enthaltene Polyfill möchten Sie das eigenständige Polyfill -Bündel bedingt laden. Die Polyfill sollte vor dem Widget -Bundle geladen werden:
<!-- Polyfill for older browsers -->
< script src =" https://global.oktacdn.com/okta-signin-widget/7.25.1/js/okta-sign-in.polyfill.min.js " type =" text/javascript " integrity =" sha384-QzQIGwIndxyBdHRQOwgjmQJLod6LRMchZyYg7RUq8FUECvPvreqauQhkU2FF9EGD " crossorigin =" anonymous " > </ script >
<!-- Widget bundle for Okta Identity Engine -->
< script src =" https://global.oktacdn.com/okta-signin-widget/7.25.1/js/okta-sign-in.oie.min.js " type =" text/javascript " integrity =" sha384-T4d68QBaFQ/b3kDy8qubuXDALwWgBRfP0JsfZsYRzZNlIXflVE2svwIHrPaivLyd " crossorigin =" anonymous " > </ script >
<!-- CSS for widget -->
< link href =" https://global.oktacdn.com/okta-signin-widget/7.25.1/css/okta-sign-in.min.css " type =" text/css " rel =" stylesheet " integrity =" sha384-63aTBe2wMqzMRsDHNmlF/FreSWmf3p08BhUDoPlzVf3d+stbkfWtqmdyJ4He5m3m " crossorigin =" anonymous " />Die Verwendung unseres NPM -Moduls ist eine gute Wahl, wenn:
So installieren Sie @okta/okta-signin-widget:
# Run this command in your project root folder
# yarn
yarn add @okta/okta-signin-widget
# npm
npm install @okta/okta-signin-widget --save Dadurch wird die neueste Version des Anmeldes-Widgets in das node_modules -Verzeichnis Ihres Projekts installiert.
Hinweis: Wenn Sie TypeScript verwenden, müssen Sie synthetische Importe in Ihrem tsconfig.json aktivieren.
{
...
"compilerOptions" : {
"allowSyntheticDefaultImports" : true ,
...
}
} Angular (TypeScript) -Projekte erfordern eine Simliar -Konfiguration, ebenfalls in Ihrem tsconfig.json
{
...
"angularCompilerOptions" : {
"allowSyntheticDefaultImports" : true ,
...
}
} Die Widget-Quelldateien und -Assets sind in node_modules/@okta/okta-signin-widget/dist installiert und haben diese Verzeichnisstruktur:
node_modules/@okta/okta-signin-widget/dist/
├── css/
│ │ # Main CSS file for widget styles
│ └── okta-sign-in.min.css
│
│ # Base font and image files that are used in rendering the widget
├── font/
│
├── img/
│
├── js/
│ │ # CDN JS file that exports the OktaSignIn object in UMD format. This is
│ │ # packaged with everything needed to run the widget, including 3rd party
│ │ # vendor files and polyfills.
│ ├── okta-sign-in.min.js
| |
│ │ # CDN JS file bundled without polyfills.
│ ├── okta-sign-in.no-polyfill.min.js
│ │
│ │ # Development version of okta-sign-in.min.js. Equipped with helpful
│ │ # console warning messages for common configuration errors.
│ └── okta-sign-in.js
│
│ # Localized strings that are used to display all text and labels in the
│ # widget. Three output formats are included - json and properties
├── labels/
│
│ # Sass files that are used to generate the widget css. If you are already
│ # using Sass in your project, you can include these helper files to make
│ # generating your custom theme easier
└── sass/Nach der Installation:
Kopieren Sie die Vermögenswerte in einen Ordner, der an Ihre öffentlich gehostete Website verteilt wird. Die Ordner, die Sie kopieren müssen, sind css , font , img , js und labels .
Anstatt das js Verzeichnis zu kopieren und es als global in Ihre Seite aufzunehmen, können Sie das Anmelde-Widget in Ihrem Build benötigen, wenn Sie WebPack, Browserify oder ein anderes Modulbündelungssystem verwenden, das das Format node_modules versteht.
// Load the Sign-In Widget module
var OktaSignIn = require ( '@okta/okta-signin-widget' ) ;
// Use OktaSignIn
var signIn = new OktaSignIn ( /* configOptions */ ) ;Quellkarten werden als externe .map -Datei bereitgestellt. Wenn Sie WebPack verwenden, können diese mit dem Quell-Map-Lader-Plugin geladen werden.
Wenn Sie Widget-Stile in das Bundle mit Style-Loader oder Mini-CSS-Extract-Plugin aufnehmen möchten, verwenden Sie den folgenden Import:
import '@okta/okta-signin-widget/css/okta-sign-in.min.css' ; Hinweis: Wenn Sie Browserify verwenden, um Ihre App zu bündeln, müssen Sie die Option --noparse verwenden:
browserify main.js
--noparse= $PWD /node_modules/@okta/okta-signin-widget/dist/js-okta-sign-in.entry.js
--outfile=bundle.jsStellen Sie sicher, dass Sie ES6 -Polyfills in Ihren Bundler einbeziehen, wenn Sie IE11 unterstützen müssen. Das Widget bietet alle benötigten Polyfüllungen durch einen Export:
const polyfill = require('@okta/okta-signin-widget/polyfill');
oder
import polyfill from '@okta/okta-signin-widget/polyfill';
Diese einfachen Beispiele sollten Ihnen dabei helfen, mit dem Anmeldes-Widget zu beginnen. Für vollständige End-to-End-Lösungen finden Sie in unseren Beispielanwendungen.
Eine einzelne Seitenanwendung (SPA) wird vollständig im Browser ausgeführt. SPA-Anwendungen authentifizieren mithilfe von Client-Seite und speichern OAuth-Token im browserbasierten Speicher.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}
) ;
signIn . showSignIn ( {
// Assumes there is an empty element on the page with an id of 'osw-container'
el : '#osw-container'
} ) . then ( function ( res ) {
// Most flows will not require any redirection. In these cases, tokens will be returned directly.
// res.tokens is an object
oktaSignIn . authClient . handleLoginRedirect ( res . tokens ) ;
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
} ) ; Eine Webanwendung wird hauptsächlich auf dem Server ausgeführt. Das Widget, das clientseitig ausgeführt wird, wird in eine HTML-Seite eingebettet, die einen Skriptblock enthält, der das Widget konfiguriert und rendert. OAuth-Token wird serverseitig auf dem Anmeldungsumweis der Anwendung empfangen.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
state : '{{state passed from backend}}' , // state can be any string, it will be passed on redirect callback
codeChallenge : '{{PKCE code challenge from backend}}' , // PKCE is required for interaction code flow
}
) ;
// When the authorization flow is complete there will be a redirect to Okta.
// Okta's servers will process the information and then redirect back to your application's `redirectUri`
// If successful, an authorization code will exist in the URL as the "code" query parameter
// If unsuccesful, there will be an "error" query parameter in the URL
signIn . showSignInAndRedirect ( {
// Assumes there is an empty element on the page with an id of 'osw-container'
el : '#osw-container'
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
} ) ; Zusätzlich zum Standardauthentifizierungsfluss unterstützt das Widget mehrere vordefinierte Flows, mit denen Sie HTML-Seiten mit Einzelpur-Purpose für mehrere häufige Anwendungsfälle bereitstellen können.
Standardmäßig wird das Okta-Anmelde-Widget entweder mit einem aktuellen Fluss fortgesetzt oder einen neuen authentifizierenden Fluss starten. Die flow -Option ermöglicht das Bootstrapping das Widget in eine bestimmte Ansicht wie Register, Entsperren oder Zurücksetzen des Kennworts. Unterstützte Ströme:
HINWEIS: Ein bestimmter Fluss kann nur funktionieren
flow: 'signup'wenn der Administrator die ORG so konfiguriert hat, dass die erforderlichen Vorgänge (Beispiel: Wenn die Anmeldung der Profile (Benutzeranmeldung) in der Administratorkonsole nicht aktiviert ist zu einem Fehler führen)
// login.html
new OktaSignIn ( {
flow : 'login'
} ) ;
// signup.html
new OktaSignIn ( {
flow : 'signup'
} ) ;
// reset_password.html
new OktaSignIn ( {
flow : 'resetPassword'
} ) ;
// unlock_account.html
new OktaSignIn ( {
flow : 'unlockAccount'
} ) ; Ein Umleitungsrückruf tritt auf, wenn Ihre App im Browser als Teil eines Flusses neu geladen wird. Während eines Umleitungsrückrufs wird die App auf einem bestimmten URL -Pfad geladen, den Sie in Ihrer Okta -App -Konfiguration definiert haben. Die meisten Rückrufe können nur einmal behandelt werden und erzeugen einen Fehler, wenn versucht wird, ihn zweimal zu handhaben. In der Regel wird sich die App in einen bekannten oder zuvor gespeicherten URL -Pfad umleiten, nachdem die Rückruflogik behandelt wurde, um Fehler auf der Seite neu zu laden.
HINWEIS: Die meisten Apps sollten bereit sein, einen oder mehrere Umleitungsrückrufe zu verarbeiten. Abhängig davon, wie die App-Sign-On-Richtlinie konfiguriert ist, können einige SPA-Anwendungen möglicherweise Token ohne Umleitung empfangen. Die Logik muss jedoch hinzugefügt werden, wenn die Richtlinie eine Anmeldung bei einem Social / IDP -Anbieter enthält oder die Authentifizierung oder Kontowiederherstellung mithilfe der E -Mail -Überprüfung ermöglicht.
Der OAuth -Rückruf ist der letzte Schritt des Interaktionscodeflusses. Bei einer erfolgreichen Authentifizierung wird der Browser mit Informationen in Okta umgeleitet, um eine neue Sitzung zu beginnen. Die Server von Oktten verarbeiten die Informationen und leiten dann auf redirectUri Ihrer Anwendung zurück. Wenn er erfolgreich ist, ist in der URL ein Interaktionscode als interaction_code -Abfrageparameter vorhanden. Wenn er nicht erfolgreich ist, gibt es in der URL error und error_description -Abfrageparameter für Fehler- und Erschreibung. Ob erfolgreich oder nicht, der state Parameter, der ursprünglich von Ihrer Anwendung an das Widget übergeben wurde, wird ebenfalls auf die Umleitung zurückgegeben. Dies kann von serverseitigen Webanwendungen verwendet werden, um dem Rückruf mit der richtigen Benutzersitzung zu entsprechen.
Alle Webanwendungen werden einen OAuth -Rückruf behandeln . Für Spa-Anwendungen ist in vielen Fällen die Sign-On-Richtlinie keine Umleitung erforderlich, und diese Anwendungen können Token direkt von Showsignin erhalten. Wenn die Sign-On-Richtlinie jedoch aus irgendeinem Grund eine Umleitung erfordert (z. B. die Integration mit einem sozialen / IDP-Anbieter), müssen Spa-Apps einen OAuth-Rückruf abwickeln. Aus diesem Grund empfehlen wir, dass alle SPA -Apps bereit sein sollten, einen OAuth -Rückruf zu verarbeiten .
HINWEIS: Das Widget behandelt einen OAuth -Rückruf nicht direkt. Serverseitige Webanwendungen können einen unserer SDKs verwenden, um den Rückruf zu unterstützen. SPA-Anwendungen können das Okta-Auth-JS-SDK verwenden, das im Anmelde-Widget als
authClientEigenschaft enthalten ist.
Eine SPA-Anwendung kann mit dem integrierten authClient die OAuth Callback-Client-Seite behandeln:
// https://myapp.mycompany.com/login/callback?interaction_code=ABC&state=XYZ
if ( signIn . authClient . isLoginRedirect ( ) ) {
await signIn . authClient . handleLoginRedirect ( ) ;
} Nachdem sich der Benutzer bei einem IDP der Drittanbieter angemeldet hat, wird der Benutzer auf die redirectUri der Anwendung zurückgeleitet. Wenn vom Benutzer keine weitere Eingabe benötigt wird, ist dies ein OAuth -Rückruf, der einen Parameter interaction_code enthält. Wenn weitere Eingaben erforderlich sind, enthält der Rückruf einen error mit der Wert interaction_required . In diesem Fall sollte das Anmelde-Widget erneut geladen werden, damit der Fluss fortgesetzt werden kann.
Sowohl serverseitige Web- als auch SPA-Anwendungen sollten nach dem Parameter " error " suchen. Wenn der Wert interaction_required ist, sollten sie das Widget erneut mit derselben Konfiguration wie das erste Rendern rendern. Der state wird auch an den Rückruf übergeben, mit dem die Anforderung mit der Anwendungssitzung des Benutzers übereinstimmt. Das Widget fährt automatisch mit der Transaktion fort.
Ihre Bewerbung muss einen E-Mail-Überprüfungs-Rückruf implementieren, wenn Ihre Anmelderichtlinie E-Mail-Magic-Link/OTP verwendet. Nachdem der Benutzer auf den Link in einer E -Mail geklickt hat, werden er zurück zum email verify callback URI der Anwendung umgeleitet. Die an die Anwendung übergebenen Abfrageparameter umfassen state und otp . Wie beim Social/IDP -Rückruf sollte das Widget mit derselben Konfiguration erneut gerendert werden. Zusätzlich sollte der otp an den Konstruktor des Widgets übergeben werden.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
state : '{{state from URL}}' ,
otp : '{{otp from URL}}'
}
) ; Erstellt eine neue Instanz des Anmelde-Widgets mit den bereitgestellten Optionen.
Für Anwendungen mit einem angepassten Okta-verabreichten Widget wird auf der Seite ein Konfigurationsobjekt vorhanden, das alle erforderlichen Werte enthält. Sie müssen dieses Objekt höchstwahrscheinlich nicht ändern.
Für Anwendungen mit einem eingebetteten Widget müssen Sie eine OIDC -Konfiguration bereitstellen:
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var signIn = new OktaSignIn (
{
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}
) ;Rendert das Widget an den DOM. Zum Erfolg löst das Versprechen. Bei Fehler lehnt das Versprechen ab. Wenn für die Sign-On-Richtlinie eine Weiterleitung von Okta oder einem anderen IDP (IDP) erforderlich ist, wird der Browser weiterleiten und das Versprechen wird sich nicht lösen. Die Antworten und Fehler sind die gleichen wie für Renderel.
Hinweis : Dies ist die empfohlene Möglichkeit, das Widget für SPA -Anwendungen zu rendern. Serverseitige Web-Apps sollten stattdessen die SendingInnandRect-Methode verwenden.
showSignIn akzeptiert die gleichen Optionen wie der Widget -Konstruktor. Optionen, die an die Methode übergeben wurden, überschreiben Optionen vom Konstruktor.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var signIn = new OktaSignIn ( {
issuer : 'https://{yourOktaDomain}/oauth2/default'
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ) ;
oktaSignIn . showSignIn ( {
// Assumes there is an empty element on the page with an id of ‘osw-container’
el : ‘ # osw - container’ ,
} ) . then ( response => {
oktaSignIn . authClient . handleLoginRedirect ( res . tokens ) ;
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
console . log ( 'login error' , error ) ;
} ) ; Rendert das Widget an den DOM. Bei einer erfolgreichen Authentifizierung wird der Browser mit Informationen in Okta umgeleitet, um eine neue Sitzung zu beginnen. Die Server von Oktten verarbeiten die Informationen und leiten dann auf redirectUri Ihrer Anwendung zurück. Wenn er erfolgreich ist, existiert in der URL ein Interaktionscode als interaction_code -Abfrageparameter. Wenn er nicht erfolgreich ist, gibt es in der URL error und error_description -Abfrageparameter für Fehler- und Schriftzeichen. Ob erfolgreich oder nicht, der state , der an das Widget übergeben wurde, wird ebenfalls zur Umleitung zurückgegeben. Dies kann von Ihrer serverseitigen Webanwendung verwendet werden, um dem Rückruf mit der richtigen Benutzersitzung zu entsprechen.
showSignInAndRedirect akzeptiert die gleichen Optionen wie der Widget -Konstruktor. Optionen, die an die Methode übergeben wurden, überschreiben Optionen vom Konstruktor.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var signIn = new OktaSignIn ( {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
state : '{{state passed from backend}}' , // state can be any string, it will be passed on redirect callback
codeChallenge : '{{PKCE code challenge from backend}}' , // PKCE is required for interaction code flow
} ) ;
signIn . showSignInAndRedirect ( {
// Assumes there is an empty element on the page with an id of 'osw-container'
el : '#osw-container'
} ) . catch ( function ( error ) {
// This function is invoked with errors the widget cannot recover from:
// Known errors: CONFIG_ERROR, UNSUPPORTED_BROWSER_ERROR
} ) ;Verstecken Sie das Widget, aber halten Sie das Widget im DOM.
signIn . hide ( ) ;Zeigen Sie das Widget, wenn sie versteckt ist.
signIn . show ( ) ;Entfernen Sie das Widget vollständig aus dem DOM.
signIn . remove ( ) ;Abonnieren Sie eine vom Widget veröffentlichte Veranstaltung.
event - Veranstaltung zum Abonnierencallback - Funktion zum Aufrufen, wenn das Ereignis ausgelöst wird // Handle a 'ready' event using an onReady callback
signIn . on ( 'ready' , onReady ) ;Abbestellen von Widget -Ereignissen. Wenn kein Rückruf vorgelegt wird, beschreibt alle Zuhörer von der Veranstaltung.
event - optionales Ereignis zum Abbestellen voncallback - Optionaler Rückruf, der zum Abonnieren der Veranstaltung verwendet wurde // Unsubscribe all listeners from all events
signIn . off ( ) ;
// Unsubscribe all listeners that have been registered to the 'ready' event
signIn . off ( 'ready' ) ;
// Unsubscribe the onReady listener from the 'ready' event
signIn . off ( 'ready' , onReady ) ;Bietet Zugriff auf das zugrunde liegende [@okta/okta-auth-js] []. Alle Methoden sind in der API -Referenz dokumentiert.
Der authClient wird mithilfe von Werten konfiguriert, die an das Widget übergeben wurden, z. B. clientId , issuer , redirectUri , state und scopes . Optionen, die vom Widget nicht direkt unterstützt werden, können mit dem authParams -Objekt an AuthJs übergeben werden.
Der authClient kann außerdem außerhalb des Widgets erstellt und konfiguriert werden und als authClient -Option an das Widget übergeben werden. Wenn eine authClient -Option übergeben wird, werden authParams ignoriert.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var authClient = new OktaAuth ( {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ) ;
var config = {
baseUrl : 'https://{yourOktaDomain}' ,
authClient : authClient ,
} ;
var signIn = new OktaSignIn ( config ) ;
// signIn.authClient === authClient Wenn keine authClient -Option festgelegt ist, wird eine Instanz mit den Optionen erstellt, die an das Widget und authParams übergeben wurden:
Hinweis : Wenn Sie die Option
authClientConfiguration verwenden, müssen Sie dieselbe Version von@okta/okta-auth-jswie das vom installierte Widget verwendet und verwenden. Diese Version finden Sie in der Dateipackage.jsondes installierten Widgets.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
authParams : {
ignoreSignature : true
}
} ;
var signIn = new OktaSignIn ( config ) ;
// signIn.authClient.options.clientId === '{yourClientId}'
// signIn.authClient.options.ignoreSignature === true'Fügt eine asynchrone Hakenfunktion hinzu, die vor einer Ansicht ausgeführt wird.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ;
var signIn = new OktaSignIn ( config ) ;
signIn . before ( 'success-redirect' , async ( ) => {
// custom logic can go here. when the function resolves, execution will continue.
} ) ;Hinweis : Diese Funktion wird nur bei der Verwendung der Okta Identity Engine unterstützt
Fügt eine asynchrone Hakenfunktion hinzu, die nach einer Ansicht ausgeführt wird.
Hinweis: Weitere Informationen zu diesen Konfigurationswerten finden Sie auf der Konfiguration
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{yourClientId}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} ;
var signIn = new OktaSignIn ( config ) ;
signIn . after ( 'identify' , async ( ) => {
// custom logic can go here. when the function resolves, execution will continue.
} ) ; Wenn Sie die Standard-Signin-Seite von Okta-veranstaltet verwenden, wird die gesamte Konfiguration über den Customization der Admin-Benutzeroberfläche behandelt.
Wenn Sie die benutzerdefinierte Seite mit Okta-veranstalteten Signin verwenden, ist auf der Seite ein Konfigurationsobjekt enthalten, das alle erforderlichen Werte enthält. Sie müssen dieses Objekt wahrscheinlich nicht ändern, können dieses Objekt jedoch als Ausgangspunkt verwenden und zusätzliche Anpassungen hinzufügen.
Bei eingebetteten Widgets sollten Sie den issuer , clientId und redirectUri einstellen. Standardmäßig wird das Widget mit dem Interaktionscodefluss auf der Identitäts -Engine ausgeführt. Das Widget kann auch gegen die klassische Engine ausgeführt werden, indem die UseClassicengine -Option auf true festgelegt wird. (Weitere Informationen zum Laufen in klassischer Motor finden Sie in diesem Dokument.
Alle eingebetteten Widgets sollten diese grundlegenden Optionen festlegen: issuer , clientId und redirectUri .
HINWEIS : OKTA-veranstaltete Widgets sollten diese Werte nicht festlegen.
Die URL des Autorisierungsservers, der Ihre Anwendung OAuth -Token ausgibt.
Hinweis :
https://{yourOktaDomain}kann jede Okta -Organisation sein. In unserem Entwicklerleitfaden finden Sie Hilfe bei der Suche nach Ihrer Okta -Domain.
Grundlegende Konfiguration mit dem benutzerdefinierten Autorisierungsserver "Standard":
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}Ein anderer benutzerdefinierter Autorisierungsserver kann angegeben werden:
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/custom' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
} Einige Anwendungen, wie z. B. solche, die Zugriff auf die Okta -Benutzer -API erfordern, möchten den Okta -Organisationsserver als Emittent verwenden. In diesem Fall sollte der issuer mit Ihrer Okta -Domain übereinstimmen:
var config = {
issuer : 'https://{yourOktaDomain}' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
}HINWEIS : Der OKTA -Organisationsautorisierungsserver ist nur für den Zugriff auf die OKTA -Benutzer -API gedacht und unterstützt nicht alle Funktionen des Standard -benutzerdefinierten Autorisierungsservers, z. B. benutzerdefinierte Scopes auf Zugriffstoken. Es wird im Allgemeinen empfohlen, einen benutzerdefinierten Autorisierungsserver zu verwenden, um den Zugriff auf die Ressourcen Ihres Unternehmens zu sichern.
Hinweis : Dieser Konfigurationswert finden Sie in der OKTA -Administrator -Benutzeroberfläche. Weitere Informationen finden Sie in unserem Entwicklerleitfaden, um die Kunden Ihrer Anwendung zu finden
Client -ID der Anwendung.
Hinweis : Dieser Konfigurationswert finden Sie in der OKTA -Administrator -Benutzeroberfläche unter den "Allgemeinen Einstellungen" der Anwendung "
Die URI, die für den OAuth -Rückruf verwendet werden muss.
Standardmäßig false . Standardmäßig verwendet das Widget den Interaktionscodefluss in der Identitäts -Engine. Wenn Sie die Option useClassicEngine in true festlegen, wird das Widget stattdessen gegen die klassische Engine ausgeführt. (Weitere Informationen zum Konfigurieren eines Widgets in klassischer Engine finden Sie in diesem Dokument.)
Hinweis : Diese Option wird zusammen mit der Unterstützung für die klassische Engine in einer zukünftigen Widget -Version entfernt. Alle Kunden werden aufgefordert, vom klassischen Motor zum Identitätsmotor zu wandern. Besuchen Sie die Migration zu OIE, um weitere Informationen zur Migration zur Identity Engine zu erhalten.
Die PKCE -Code -Herausforderung. SPA -Anwendungen benötigen diese Option nicht, da das Widget die gesamte Transaktion verwaltet. Webanwendungen sollten ihre eigene Code Challenge und Code Secret generieren. Die Code-Herausforderung wird an das Widget übergeben, und das Code-Geheimnis wird serverseitig gehalten, um Token für den Anmeldeinruf von Redirect zu erhalten.
Hinweis : Schauen Sie sich unsere Beispielanwendungen für vollständige Arbeitsbeispiele für den Interaktionscodefluss unter Verwendung von PKCE an
Ein Anwendungswert, der als Abfrageparameter zurückgegeben wird, während des Rückrufs oder E-Mail-Rückrufs für den Umleitungsanmeldung. Wenn kein Wert festgelegt wird, wird ein zufälliger Wert erstellt. Bei der Behandlung einer E -Mail -Überprüfungs -Rückruf sollte der Wert des state aus dem Abfrageparameter als Konfigurationsoption (zusammen mit OTP) an das Widget übergeben werden. Dadurch wird sichergestellt, dass das Widget die aktuelle Transaktion laden und fortsetzen kann.
Bei der Behandlung einer E -Mail -Überprüfung des Rückrufs sollte der Wert von otp aus dem Abfrageparameter als Konfigurationsoption (zusammen mit dem Status) an das Widget übergeben werden. Dadurch wird sichergestellt, dass das Widget die aktuelle Transaktion laden und fortsetzen kann.
Standardeinstellungen zu ['openid', 'email'] . Geben Sie an, welche Informationen in der zurückgegebenen id_token oder access_token verfügbar sind. Für OIDC müssen Sie openid als einen der Bereiche einbeziehen. Eine Liste der verfügbaren Bereiche finden Sie in Scopes und Ansprüchen.
Zeigen Sie die Reihenfolge für externe Identitätsanbieter in Bezug auf das Okta -Anmeldeformular an. Standardeinstellungen zu SECONDARY .
PRIMARY - Zeigen Sie externe IDP -Schaltflächen über dem OKTA -Anmeldformular anSECONDARY - Zeigen Sie externe IDP -Schaltflächen unterhalb des Okta -Anmeldeformulars anLokaler Pfad oder URL zu einem Logo-Bild, das oben im Anmeldewidget angezeigt wird
// Hosted on the same origin
logo: '/img/logo.png'
// Can also be a full url
logo: 'https://acme.com/img/logo.png' Text für alt -Attribut des Logo -Bildes wird der Logo -Text nur angezeigt, wenn das Logo -Bild nicht verfügbar ist
// Text to describe the logo
logoText: 'logo text' Der Marken- oder Firmenname, der in Nachrichten angezeigt wird, die vom Anmeldewidget wiedergegeben werden (z. B. "Setzen Sie Ihr { brandName } -Kennwort zurück"). Wenn kein brandName bereitgestellt wird, wird stattdessen eine generische Nachricht abgegeben (z. B. "Ihr Passwort zurücksetzen"). Sie können den Text, der mit Sprach- und Texteinstellungen angezeigt wird, weiter anpassen.
brandName: 'Spaghetti Inc.' Mit diesen Optionen können Sie das Erscheinungsbild des Anmelde-Widgets anpassen.
Wenn Sie noch mehr Anpassung möchten, können Sie die SASS -Quelldateien ändern und das Widget erstellen.
Legt die Markenfarbe als Hintergrundfarbe der primären CTA -Taste fest. Farben müssen im Hex -Format wie #008000 sein.
colors: {
brand : '#008000'
}cs - Tschechischda - Dänischde - Deutschel - Griechischen - Englisches - Spanischfi - Finnischfr - Französischhu - Ungarischid - Indonesischit - Italienischja - Japanischko - Koreanischms - Malaysiannb - Norwegischnl-NL - Niederländischpl - Politurpt-BR - Portugiesisch (Brasilien)ro - Rumänischru - Russischsv - Schwedischth - Thaitr - türkischuk - Ukrainischzh-CN - Chinesisch (PRC)zh-TW - Chinesisch (Taiwan)Die Unterstützung für zusätzliche Sprachen kann mit der Option "Assets.languages" hinzugefügt werden.
Legen Sie die Sprache des Widgets fest. Wenn keine Sprache angegeben ist, wählt das Widget eine Sprache basierend auf den Browsereinstellungen des Benutzers aus, wenn es unterstützt wird, oder standardmäßig für en .
// You can simply pass the languageCode as a string:
language: 'ja'
// Or, if you need to determine it dynamically, you can pass a
// callback function:
language: ( supportedLanguages , userLanguages ) => {
// supportedLanguages is an array of languageCodes, i.e.:
// ['cs', 'da', ...]
//
// userLanguages is an array of languageCodes that come from the user's
// browser preferences
return supportedLanguages [ 0 ] ;
} Legen Sie den Standard CountryCode des Widgets fest. Wenn kein defaultCountryCode bereitgestellt wird, gibt es für US Standardeinstellungen. Es legt den Code des Landes für die Telefonnummer im Widget entsprechend fest.
Überschreiben Sie den Text im Widget. Die vollständige Liste der Eigenschaften finden Sie in der Login.Properties and Country.Properties -Dateien.
// The i18n object maps language codes to a hash of property keys ->
// property values.
i18n: {
// Overriding English properties
'en' : {
'primaryauth.title' : 'Sign in to Acme' ,
'primaryauth.username.placeholder' : 'Your Acme Username'
} ,
// Overriding Japanese properties
'ja' : {
'primaryauth.title' : 'ACMEにサインイン' ,
'primaryauth.username.placeholder' : 'ACMEのユーザー名'
}
}
// If you want to override any properties in the country.properties file,
// you will need to prefix the name with "country.":
i18n: {
'en' : {
// login.properties keys do not have a special prefix
'primaryAuth.title' : 'Sign in to Acme' ,
// country.properties keys are prefixed with 'country.'
'country.AF' : 'Afghanistan, edited' ,
'country.AL' : 'Albania, edited'
}
}Überschreiben Sie die Basis -URL Das Widget zieht seine Sprachdateien aus. Das Widget ist nur standardmäßig mit englischer Text verpackt und lädt andere Sprachen auf Bedarf von der Okta -CDN. Wenn Sie die Sprachdateien von Ihren eigenen Servern bedienen möchten, aktualisieren Sie diese Einstellung.
// Loading the assets from a path on the current domain
assets: {
baseUrl : '/path/to/dist'
} ,
// Full urls work as well
assets : {
baseUrl : 'https://acme.com/assets/dist'
}Hinweis: Die JSON -Dateien können aus dem im NPM -Modul veröffentlichten Ordner
dist/labels/jsonzugegriffen werden.
Geben Sie die Liste der unterstützten Sprachen an {assets.baseUrl}/labels/json/ die unter dem Pfad gehostet und zugänglich sind. Diese Option ersetzt die Standardliste der unterstützten Sprachen. Wenn eine nicht unterstützte Sprache angefordert wird (explizit die Sprachoption oder automatisch durch Browsererkennung), wird die Standardsprache ( en ) verwendet.
Sie können diese Funktion verwenden, um den Vermögensweg und den Dateinamen neu zu schreiben. Verwenden Sie diese Funktion, wenn Sie die Asset -Dateien auf Ihrem eigenen Host hosten und planen, den Pfad oder den Dateinamen der Vermögenswerte zu ändern. Dies ist beispielsweise nützlich, wenn Sie die Dateien untersuchen möchten.
assets: {
// Note: baseUrl is still needed to set the base path
baseUrl : '/path/to/dist' ,
rewrite : ( assetPath ) => {
// assetPath is relative to baseUrl
// Example assetPath to load login for 'ja': "/labels/json/login_ja.json"
return someCacheBust ( assetPath ) ;
}
}Legen Sie die folgende Konfigurationsoption fest, um die Rückseite in die Link -URL zu überschreiben. Wenn nicht bereitgestellt, navigiert das Widget zu Primärauth.
backToSignInLink: 'https://www.backtosignin.com'Hinweis: Für die Kompatibilität mit früheren Widget -Versionen wird
signOutLinkals Alias fürbackToSignInLinkakzeptiert
Sie können der Seite "Primärauthaut" einen Registrierungslink hinzufügen, indem Sie die folgenden Konfigurationsoptionen einstellen.
Funktion, die aufgerufen wird, wenn der Registrierungslink geklickt wird.
// An example that adds a registration link underneath the login form on the primary auth page
registration: {
click : ( ) => {
window . location . href = 'https://acme.com/sign-up' ;
}
} Legen Sie die folgenden Konfigurationsoptionen fest, um die Hilfelink -URLs auf der primären Auth -Seite zu überschreiben.
// An example that overrides all help links, and sets two custom links
helpLinks: {
help : 'https://acme.com/help' ,
forgotPassword : 'https://acme.com/forgot-password' ,
unlock : 'https://acme.com/unlock-account' ,
custom : [
{
text : 'What is Okta?' ,
href : 'https://acme.com/what-is-okta'
} ,
{
text : 'Acme Portal' ,
href : 'https://acme.com' ,
target : '_blank'
}
]
} Benutzerdefinierte Link HREF für den "Hilfe" -Link
Benutzerdefinierte Link HREF für den Link "Passwort vergessen"
Benutzerdefinierte Link HREF für den Link "Konto entspannen". Damit dieser Link zur Anzeige features.selfServiceUnlock true
Array von benutzerdefinierten Linkobjekten {text, href, target} das nach dem Link "Hilfe" hinzugefügt wird. Das target des Links ist optional.
Legen Sie die folgenden Konfigurationsoptionen fest, um hCaptcha -Skript -URI anzupassen:
// An example that uses cn1 host
hcaptcha : {
scriptSource : 'https://cn1.hcaptcha.com/1/api.js' ,
scriptParams : {
apihost : 'https://cn1.hcaptcha.com' ,
endpoint : 'https://cn1.hcaptcha.com' ,
assethost : 'https://assets-cn1.hcaptcha.com' ,
imghost : 'https://imgs-cn1.hcaptcha.com' ,
reportapi : 'https://reportapi-cn1.hcaptcha.com' ,
}
} , Legen Sie die folgenden Konfigurationsoptionen fest, um reCAPTCHA -Skript -URI anzupassen:
// An example that uses recaptcha.net
recaptcha : {
scriptSource : 'https://recaptcha.net/recaptcha/api.js'
} ,Asynchrone Rückrufe können vor oder nach einer bestimmten Ansicht aufgerufen werden. Hooks können verwendet werden, um benutzerdefinierte Logik wie Instrumentierung, Protokollierung oder zusätzliche Benutzereingabe hinzuzufügen. Die normale Ausführung wird blockiert, während die Hakenfunktion ausgeführt wird, und wird fortgesetzt, nachdem das Versprechen aus der Hakenfunktion zurückgegeben wird. Hooks können wie unten oder zur Laufzeit mit den Vor- oder Nachher -Methoden über die Konfiguration hinzugefügt werden. Die vollständige Liste der Ansichten finden Sie in RemediationConstants.js.
// Hooks can be set in config
hooks: {
'identify' : {
after : [
async function afterIdentify ( ) {
// custom logic goes here
}
]
} ,
'success-redirect' : {
before : [
async function beforeSuccessRedirect ( ) {
// custom logic goes here
}
]
}
}
// Hooks can also be added at runtime
signIn . before ( 'success-redirect' , async ( ) => {
// custom logic goes here
} ) ;
signIn . after ( 'identify' , async ( ) => {
// custom logic goes here
} ) ;Verwandelt den Benutzernamen, bevor Sie Anfragen mit dem Benutzernamen an Okta senden. Dies ist nützlich, wenn Sie eine interne Zuordnung zwischen dem, was der Benutzer betritt, und seinem Okta -Benutzernamen haben.
// The callback function is passed two arguments:
// 1) username: The name entered by the user
// 2) operation: The type of operation the user is trying to perform:
// - PRIMARY_AUTH
// - FORGOT_PASSWORD
// - UNLOCK_ACCOUNT
transformUsername: ( username , operation ) => {
// This example will append the '@acme.com' domain if the user has
// not entered it
return username . includes ( '@acme.com' )
? username
: username + '@acme.com' ;
}Rückruffunktionen können bereitgestellt werden, die in bestimmten Momenten im Registrierungsprozess aufgerufen werden.
registration : {
parseSchema : ( schema , onSuccess , onFailure ) => {
// handle parseSchema callback
onSuccess ( schema ) ;
} ,
preSubmit : ( postData , onSuccess , onFailure ) => {
// handle preSubmit callback
onSuccess ( postData ) ;
} ,
postSubmit : ( response , onSuccess , onFailure ) => {
// handle postsubmit callback
onSuccess ( response ) ;
}
} , Der Rückruf änderte früher das JSON -Schema, das von der Okta -API zurückkommt.
parseSchema: ( schema , onSuccess ) => {
// This example will add an additional field to the registration form.
schema . push (
{
'name' : 'userProfile.address' ,
'type' : 'text' ,
'placeholder' : 'Enter your street address' ,
'maxLength' : 255 ,
'label-top' : true ,
'label' : 'Street Address' ,
'required' : true ,
}
) ;
onSuccess ( schema ) ;
} Rückruf verwendet hauptsächlich, um die an die Okta -API gesendeten Anforderungsparameter zu ändern.
preSubmit: ( postData , onSuccess ) => {
// This example will append the domain name to the email address if the user forgets to add it during registration.
if ( ! postData . userProfile . email . includes ( '@acme.com' ) ) {
postData . userProfile . email += '@acme.com' ;
}
}
onSuccess ( postData ) ;
} Rückruf verwendet, um in erster Linie die Kontrolle zu erhalten und das Verhalten nach Einreichung der Registrierungs -API zu ändern.
postSubmit: ( response , onSuccess ) => {
// This example will log the API request body to the browser console before completing registration.
console . log ( response ) ;
onSuccess ( response ) ;
} preSubmit: ( postData , onSuccess , onFailure ) => {
// A generic form level error is shown if no error object is provided
onFailure ( ) ;
} preSubmit: ( postData , onSuccess , onFailure ) => {
const error = {
"errorSummary" : "Custom form level error"
} ;
onFailure ( error ) ;
} preSubmit: ( postData , onSuccess , onFailure ) => {
const error = {
"errorSummary" : "API Error" ,
"errorCauses" : [
{
"errorSummary" : "Custom field level error" ,
"property" : "userProfile.email" ,
}
]
} ;
onFailure ( error ) ;
} Sie können benutzerdefinierte Schaltflächen unter dem Anmeldeformular auf der Seite Primärauth addieren, indem Sie die folgenden Konfigurationsoptionen einstellen. Wenn Sie den Teilertext ändern möchten, verwenden Sie die Option i18n config.
// An example that adds a custom button below the login form on the Sign in form
customButtons: [ {
title : 'Click Me' ,
className : 'btn-customAuth' ,
click : ( ) => {
// clicking on the button navigates to another page
window . location . href = 'https://www.example.com' ;
}
} ]
// An example that adds a custom button with a localized title below the Sign in form
i18n: {
en : {
'customButton.title' : 'Custom Button Title' ,
} ,
} ,
customButtons : [ {
i18nKey : 'customButton.title' ,
className : 'btn-customAuth' ,
click : ( ) => {
// clicking on the button navigates to another page
window . location . href = 'https://www.example.com' ;
}
} ] Zeichenfolge, die als Schaltflächentext festgelegt wird (nur einen von title oder i18nKey festlegen)
Benutzerdefinierte Übersetzungsschlüssel für Schaltflächentext in i18n -Konfigurationsoption angegeben (nur einen von title oder i18nKey festlegen)
Optionale Klasse, die zur Taste hinzugefügt werden kann
Funktion, die aufgerufen wird, wenn die Schaltfläche angeklickt wird
Aktivieren oder deaktivieren Sie die Widget -Funktionalität mit den folgenden Optionen.
features: {
showPasswordToggleOnSignInPage : true ,
hideSignOutLinkInMFA : false ,
rememberMe : true
} Standardmäßig true . Zeigt das Eye-Symbol an, um die Sichtbarkeit des eingegebenen Benutzerkennworts auf der OKTA-Anmeldeseite umzuschalten. Das Passwort ist standardmäßig versteckt, auch wenn dieses Flag aktiviert ist. Passwörter sind 30 Sekunden lang sichtbar und dann automatisch versteckt.
Standardmäßig true . Zeigt die Kennung des Benutzers in jeder Ansicht mit dem Benutzerkontext an.
Standardmäßig false . Verbirgt den Link "Zurück zum Anmelden" für Authenticator -Registrierung und Herausforderungsströme.
Standardmäßig true . Vor dem Füllen Sie das Feld Identifier mit dem zuvor verwendeten Benutzernamen vor.
Standardmäßig true . Fokussiert automatisch das erste Eingangsfeld eines beliebigen Formulars, wenn sie angezeigt werden.
Standardmäßig false . Legt das AutoComplete -Attribut auf Eingabefeldern auf off fest.
Das Widget injiziert Secure Inline -Skript-/Stilblöcke zur Laufzeit für den Anpassungszweck, diese Blöcke können jedoch gegen CSP -Regeln verstoßen, die auf der gehosteten Webseite festgelegt sind.
cspNonce ermöglicht den festgelegten Nonce-Wert von Content-Security-Policy Header auf die injizierten Blöcke, so dass Skript/Stil aus diesen Blöcken weiterhin ausführbar sein kann.
Hinweis: Die Nonce -Anweisung wurde zu CSP Level2 hinzugefügt. Möglicherweise sehen Sie CSP -Fehler in der Browserkonsole, wenn sie in nicht unterstützten Browsern verwendet werden.
Ereignisse, die vom Widget veröffentlicht wurden. Abonnieren Sie diese Ereignisse mit.
Ausgelöst, wenn das Widget zum ersten Mal die Benutzereingaben akzeptieren kann. Gibt ein context zurück, das die folgenden Eigenschaften enthält:
signIn . on ( 'ready' , function ( context ) {
// The Widget is ready for user input
} ) ; Das Widget behandelt die meisten Arten von Fehlern - beispielsweise, wenn der Benutzer ein ungültiges Kennwort eingibt oder es Probleme gibt, die sich authentifizieren. Um einen Authentifizierungszustandsänderungsfehler zu erfassen, nachdem er vom Widget bearbeitet und wiedergegeben wurde, hören Sie sich das afterError -Ereignis an. Sie können auch OAuth- und Registrierungsfehler erfassen. Bei anderen Fehlertypen wird ermutigt, sie mit dem renderEl -Fehlerhandler zu handhaben.
Gibt context und error zurück, die die folgenden Eigenschaften enthalten:
context :error : signIn . on ( 'afterError' , function ( context , error ) {
console . log ( context . controller ) ;
// reset-password
console . log ( error . name ) ;
// AuthApiError
console . log ( error . message ) ;
// The password does not meet the complexity requirements
// of the current password policy.
console . log ( error . statusCode ) ;
// 403
} ) ; Triggered when the widget transitions to a new page and animations have finished. Returns a context object containing the following properties:
// Overriding the "Back to sign in" click action on the Forgot Password page
signIn . on ( 'afterRender' , function ( context ) {
if ( context . controller !== 'forgot-password' ) {
return ;
}
var backLink = document . getElementsByClassName ( 'js-back' ) [ 0 ] ;
backLink . addEventListener ( 'click' , function ( e ) {
e . preventDefault ( ) ;
e . stopPropagation ( ) ;
// Custom link behavior
} ) ;
} ) ; We use Yarn as our node package manager. To install Yarn, check out their install documentation.
Clone this repo and navigate to the new okta-signin-widget folder.
git clone https://github.com/okta/okta-signin-widget.git
cd okta-signin-widgetInstall our Node dependencies.
yarn install Create a .widgetrc.js file in the okta-signin-widget directory with your desired configuration:
module . exports = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : '{{clientId of your OIDC app}}' ,
redirectUri : '{{redirectUri configured in OIDC app}}' ,
logoText : 'Windico' ,
features : {
rememberMe : true ,
} ,
}Build the widget, start a local connect server that hosts it, and launch a browser window with the widget running.
yarn start or start local connect server in watch mode, changes in src/ and assets/sass/ folders will trigger browser auto reload.
yarn start --watchFinally, enable CORS support for our new server by following these instructions. You can now authenticate to Okta using your very own, customizable widget!
| Befehl | Beschreibung |
|---|---|
yarn start | Build the widget, start the server, and open a browser window with the widget loaded |
yarn start --watch | Build the widget, start the server, and open a browser window with the widget loaded and watch on widget js and sass changes |
yarn build:dev | Build an unminified version of the widget |
yarn build:release | Build a minified, uglified version of the widget ( okta-sign-in.min.js ) and a non-minified development version of the widget ( okta-sign-in.js ). |
yarn test -t jest | Run unit tests using Jest |
yarn test -t jest --suiteHelp | Display optional test suite options |
yarn test -t testcafe <browser> | Run testcafe tests on selected browser (example: yarn test -t testcafe chrome ) |
yarn lint | Run eslint and scss linting tests |
yarn link When developing locally, you may want to test local changes to the widget in another project, which is also local. To use yarn link locally, follow these steps:
In okta-signin-widget directory:
yarn build:release
cd dist
yarn link
yarn build:webpack-dev --output-path ./dist/js --output-filename okta-sign-in.entry.js --watchThis will watch for changes in signin widget source code and automatically rebuild to the dist directory.
In your other local project directory:
yarn link @okta/okta-signin-widget
Euen This tool requires access to Okta's internal registry via the VPN.
A pseudo-localized language is a test language created to identify issues with the internationalization process. Generated from login.properties English resources, the pseudo-loc properties file can be used to test UI's for English leaks and CSS layout issues caused due to localization.
To generate pseudo-loc, run the following command:
# Navigate into the pseudo-loc package
[okta-signin-widget]$ cd packages/@okta/pseudo-loc/
# Install all required dependencies and generate login_ok_PL.properties
# NOTE: This requires VPN access
[pseudo-loc]$ yarn install
[pseudo-loc]$ yarn pseudo-loc Finally, update the .widgetrc.js file to use the ok_PL language, and start the widget playground.
module . exports = {
// ...other widget config
// ...
language : 'ok-PL' ,
...
} Need to know if the Sign-In Widget supports your browser requirements? Please see Platforms, Browser, and OS Support.
We're happy to accept contributions and PRs! Please see the contribution guide to understand how to structure a contribution.
