Login

The Login flow lets a visitor authenticate against your storefront. DynamicWeb captures credentials on any page form post containing username and password or request for external authentication. DynamicWeb then validates the user, issues an authentication cookie, and redirects based on available parameters or user settings.

Refer to the Logoff example for ending a user session.

How login is triggered

DynamicWeb supports two ways to initiate authentication:

• Regular storefront login
• External login flow

A form POST containing username and password (and optionally shopid) invokes the standard login pipeline using the user database in DynamicWeb:

1. The server checks that the username and password fields are present and non-empty.
2. Credentials (and optional shopid) are passed to the LogOnManager for validation.
3. On success, the LogOnHandler issues the authentication cookie and redirects according to the configured rules.

Parameter	Type	Description
username	string	User’s login name. Must be included in form for login.
password	string	User’s password. Must be included in form for login.
shopid	string	(Optional) Identifies the store or tenant when a user belongs to multiple shops.
redirect	string	(Optional) URL to send the user after login (absolute or relative, e.g., /Account).
cancelredirect	boolean	(Optional) If true, skips automatic redirect and returns 200 OK. Useful for AJAX-based flows.

Please note that ?redirect=false is treated as cancelredirect=true for legacy compatibility.

For both login methods, please ensure that your <form> uses method="post".

Redirect logic on success

Once credentials are verified and the authentication cookie is set, the system chooses where to send the user:

• cancelredirect: If true, stops further redirects (returns 200 OK).
• redirect: If provided, the user is redirected to that URL.
• User start page: If the user (or their group) has a configured FrontendStartPage, they are sent there.
• Referer header: Falls back to the page that initiated the login, if present.
• Default: If none apply, redirects to the storefront home page (/).

What can fail (Regular DynamicWeb Login)

The LogOnManager guards against several failure scenarios, returning a LogOnResult with Success = false and a FailedReason code:

• Empty username: No login attempt is made.
• Account blocked: Too many failed attempts; user must wait or contact support.
• Failed limit exceeded: Reached configured login-attempt limit.
• Invalid password length: Password too short, too long, or matches common hash lengths.
• Incorrect credentials: Username/password mismatch.
• Password expired: User’s password has passed the expiry date.

Tip: Inspect LogOnResult.FailedReason in the login template to provide user-friendly error messages.

Authenticating with external login providers

When you configure OAuth/OpenID Connect providers in the DynamicWeb administration (see External Login Providers documentation), you can delegate authentication to those external systems:

1. The storefront form posts DwExternalLoginProvider with the provider’s configuration ID (and optional redirect/cancelredirect parameters).
2. The middleware issues an HTTP redirect to the external provider’s login/consent page.
3. After successful authentication, the provider redirects back to your storefront callback endpoint.
4. DynamicWeb processes the external response, issues its own authentication cookie, and applies the standard post-login redirect logic.

This flow removes the need to collect or store passwords in your storefront, relying instead on the external identity provider for credential management.

AJAX-based login

If you prefer a client-driven flow, disable redirects by including ?cancelredirect=true. Then handle the JSON or status code in JavaScript:

const response = await fetch('/?cancelredirect=true', {
  method: 'POST',
  headers: {'Content-Type':'application/x-www-form-urlencoded'},
  body: new URLSearchParams({username, password})
});
if (response.ok) {
  // Check headers or JSON and navigate manually
  window.location.href = '/Dashboard';
} else {
  // Show error
}

The above example works with DynamicWeb Regular Login, and not with external logins.

Impersonation and switching account (user)

DynamicWeb offers two advanced session flows beyond standard login:

• Impersonation: Administrators or users granted the Impersonation permission can assume another user’s identity to manage scenarios on their behalf. For example:

  Impersonator	Target User
  admin@somedomain.com	some@domain.com

• Switch user: For logins that own multiple storefront accounts under the same username but different customer/shop IDs, users can seamlessly switch between those accounts without re-entering credentials. For example:

  username	customer number	shopid
  some@domain.com	abc123
  some@domain.com	zxc345	shop1
  some@domain.com	qwe678	shop2

To trigger these session flows:

• Impersonation
• Switching user

• Start impersonation: Posting DWExtranetSecondaryUserSelector (with a valid user ID) initiates impersonation of that user (requires Impersonation permission).
• Stop impersonation: Posting DwExtranetRemoveSecondaryUser ends the current impersonation session and reverts to the original user.

The following parameters are related to these functionalities:

Parameter	Type	Description
DWExtranetSwitchUser	integer	The target user’s ID (User.Id) to switch into—this identifies the user ID, not the username. Example: ?DWExtranetSwitchUser=123
DWExtranetSecondaryUserSelector	integer	The target user’s ID (User.Id) to impersonate (requires Impersonation permission). Example: ?DWExtranetSecondaryUserSelector=456
DwExtranetRemoveSecondaryUser	boolean	Stop any ongoing impersonation and revert to the original user session. Example: ?DwExtranetRemoveSecondaryUser=true
redirect	string	(Optional) URL to send the user after switch or impersonation. Example: ?redirect=/home
cancelredirect	boolean	If true, skips redirect and returns 200 OK, useful for AJAX-driven workflows. Example: ?cancelredirect=true

Two options for switching multi‑account users

When a single login (same username) corresponds to multiple DynamicWeb user records (different customernumber/shopid), you have two ways to change context:

• Switch account (DWExtranetSwitchUser)

  • Instantly swap into another of your own accounts without re-authenticating.
  • Cannot be “stopped”—to return, issue another switch or log off and log back in.
  • Ideal for users who simply need to toggle between distinct profiles (e.g., different ERP customer numbers).

• Self-impersonation (DWExtranetSecondaryUserSelector + DwExtranetRemoveSecondaryUser)

  • Treat one of your other accounts as an impersonation target; DynamicWeb records your original identity so you can revert.
  • Cleanly stop impersonation by posting DwExtranetRemoveSecondaryUser, returning you to your initial session.
  • Useful when you need an audit trail or temporary context without losing your original session state.

When to use which:

• Use switch account for quick, transient swaps between multiple tenant or customer profiles you own.
• Use self‑impersonation when you need to maintain a clear revert path (and claims) back to your original session.

The redirect logic on success follows the same sequence as a regular login:

• cancelredirect: stops further redirects (200 OK).
• redirect: sends to the provided URL.
• User start page: the configured FrontendStartPage for the new or impersonated user account.
• Referer header: falls back to the page that initiated the switch/impersonation.
• Default: redirects to the storefront home page (/).

Implementation notes

• Login submissions are idempotent: successful posts set HTTP 302/301 and stop further processing, which means that if you submit username and password to a page, that page is not rendered - as the user is redirected back to original page or on to another page.
• Authentication uses the Dynamicweb.Extranet cookie scheme and issues a Set-Cookie header.
• Notifications fire before and after login (OnBeforeExtranetLogin, OnExtranetLogin, OnExtranetLoginFailed) for extensions or custom logging.
• Impersonation and user-switch features also reuse the same sign-in logic—see LogOnHandler.SwitchUser and StartImpersonation.