Passport SDK v5.0
  • Overview
  • Account Lifecycle
  • Integration
    • Client Side Enablement
    • Credenza Presence (Optional Visual Elements)
    • Account Provisioning (Sign-up)
      • New Authentication System
      • Existing Authentication System - New Customer
      • Existing Authentication System - Existing Customer
  • Passport Subsequent Logins
  • Post-Login Capabilities
    • Account Information Access
    • Blockchain Wallet Access
  • Smart Contract Interactions
    • Instantiating The Contract Object (Server-Side)
    • Instantiating The Contract Object (Client-side)
    • Calling Contracts
  • Monetary Transactions
  • Appendix I: Passport Configuration Options
    • Magic
    • Ethers.js
    • Installation
    • Usage
    • Passport Instance Properties
    • Passport Static Properties
    • Modes
    • Supported query params
  • Transaction UI v3.0 (now part of Passport)
    • Magic
    • Ethers.js
    • Installation
    • Usage
    • Apple Pay
    • Google Pay
    • Methods
    • Events
  • Appendix II: MetaMembership Contract Access
  • Appendix III: Ledger Contract Access
  • Appendix IV: Decentralized Commerce Configuration
Powered by GitBook
LogoLogo

©2023 Credenza. All rights reserved.

On this page

Passport Subsequent Logins

Implementing logins after registration will follow the same form as registration, except the onUpdateProfile event will not trigger. Session state can be configured by Credenza, but defaults to 7 days. If it has been longer than 7 days, the request for this can come in one of two ways.

  • Active Login – On the rendering of a page, a page can require preemptively require Credenza Passport login verification to ensure everything is ready and all Passport facilities are instantly accessible. This may cause friction for users that don’t want to go through the login process if they don’t need to.

  • Passive Login – Passport has the ability to be passive about requesting access, which means that it can wait until a blockchain operation requiring a signature is called before it requests credentials. This delays the friction, but may come at an inopportune time.

Both of these approaches are acceptable and should be considered based on the optimal experience for the user experience for the specific site.

PreviousExisting Authentication System - Existing CustomerNextPost-Login Capabilities

Last updated 2 years ago