Atomic storefront session rotation
Following Single active storefront session per customer, we are rolling out a reliability improvement to how a second storefront sign-in invalidates a customer’s earlier session. Rotating the customer session token and its expiry now happens as one all-or-nothing update, so a partial failure during sign-in no longer leaves an earlier session for the same customer working.
- All-or-nothing rotation - when a customer signs in again on your storefront, the write that ends their earlier sessions either fully completes or fails, instead of silently leaving the old session active.
- Clean failure instead of silent success - if the rotation write cannot complete, the sign-in reports the failure and the failure is logged; the old token is never half-updated.
For details, see Customer login.
Custom quote templates can name the quote’s shipping method
Custom quote templates in B2B Edition can now show which shipping method a quote uses, the way the built-in templates already do. The new {{ shipping_method }} variable renders the method’s name, or Customer choice at checkout when the quote has no method yet.
- Template content: add
{{ shipping_method }}beside{{ shipping_total }}or{{ formatted_shipping_total }}to label the shipping amount. - Preview: the Preview tab renders the variable with a sample value before you save.
- Base template: new templates include the variable in the shipping row.
For details, see Quote Templates.
Sales Rep access to quote templates
B2B Edition users with the built-in Sales Rep role can now send quote emails and download quote PDFs from the control panel without a permission error.
- Send E-mail and Download PDF - Sales Reps no longer get a permission denied response when these actions load quote templates, and they do not need the Update Settings permission to use them.
- Role editor - the Send E-mail and Download PDF permissions now include access to quote templates, so custom roles can grant the same access.
- Other permissions - Update Settings and every other permission behave as before.
For details, see Quote Templates.
Storefront GraphQL login lockout is counted per IP address, not per store
Thanks to user feedback, the customer login mutation no longer rejects valid credentials because of failed sign-ins from a different IP address.
- Failed sign-ins are counted per IP address rather than per store: a failed attempt is counted against the address it arrives from, so failed sign-ins from one address no longer lock out logins from another. Under the previous store-wide counter, three failures from any shopper blocked every login on the store.
- Shoppers who share a public IP address still share a counter: a household, office, or VPN egress counts as one address, so a failure from one shopper there can block another shopper on that same address.
- A lockout reports the right error: a sign-in blocked by the failed-attempt limit returns
Too many requestsinstead ofInvalid credentials. Retry after a few seconds in that case rather than treating it as a rejected password. - Requests that arrive through a proxy: if your traffic reaches BigCommerce through a proxy that does not forward the shopper’s IP address, failed attempts are counted against that proxy’s address instead. When every login for a store arrives through one such proxy, those logins share a single counter, which brings back a store-wide lockout for them.
Failed-attempt limits, lockout duration, and the rest of the login response are unchanged.
For how the login mutation works, see Signing customers in.