Changelog - 2026-11-06

An application id keeps two applications on one origin apart

New Feature

In one line. Two ARDOR applications served from one origin used to share one session and one @app/store/ namespace. Give each an id in its application info and their keys are separate.

const info = { name: 'Shop', version: '1.0.0', description: 'The shop', id: 'shop' };
// the session is now @app/auth/shop/token, @app/auth/shop/identity and @app/auth/shop/permission,
// the store prefix @app/store/shop/

What changed

• IApplicationInfo.id. Optional; letters, digits, ., _ and -, not dots only. An invalid id stops DefaultAuthService from being built.
• LocalStorageKeys.scoped({ id }) answers the keys of one application; without an id they are the existing constants.
• One place. DefaultAuthService reads the id from CoreBindings.APPLICATION_INFO and exposes keys. Its cleanUp, DefaultAuthProvider's sign-out sweep of the store and the request service's default token all use it, so signing out of one application leaves the other's session and data alone. The keys stay under @app/auth/, which BrowserStorage still refuses to write.
• A subclass of DefaultAuthService with its own constructor passes the application info on (super(info)); DefaultAuthProvider refuses to start with a service that lost the id, so the session cannot silently stay shared.
• An old session is left where it was. Keys under a previous scope (the unscoped ones, or another id) are not read, moved or removed, so an old token stays on disk until it is removed by hand or by an application that sweeps that scope.
• DefaultNetworkRequestService.readAuthTokenFromStorage is for applications with no id. An application with an id hands its data source getDataSourceAuth() of the data provider instead.
• Added DefaultNetworkRequestService.createAuthTokenReader: Returns a token reader for an application by its ID so HttpDataSource instances can resolve the matching sign-in token from storage. Omitting the ID preserves the default application token lookup, while an invalid ID throws immediately on creation.
• No id, no change. An application without an id keeps the keys it has, so there is nothing to migrate. An application with an id starts with an empty session under the new keys: its users sign in once.

Who is affected

• Applications that share an origin. Give each an id. One without an id still sweeps all of @app/auth/ and @app/store/ at sign-out, the others' keys included.
• All other applications. No action needed.