While working in Channel Studio, a red notification may appear in the top-right corner:

Your session expired. Please sign in again - your unsaved work stays in this tab until you leave.

This page explains what the message means, what can cause it, and how to recover without losing work. The first section is written for everyone; the second section is for IT staff and developers.

For Everyone (Non-Technical)

What the message means

OnePass no longer recognizes your sign-in, so the last thing you did in Channel Studio (opening a channel, saving, renaming, uploading) was not accepted by the server. The page itself stays on screen, and any edits you have made are still held safely inside the tab - they simply have not been saved yet.

Why it can happen

• The system was updated or restarted. When an update is deployed to OnePass or the server restarts, everyone who was signed in at that moment can be signed out at once. This is the most likely cause when the message appears even though you were recently active.

• The tab sat open for a long time. A sign-in lasts up to two days without activity. A Channel Studio tab left open over a weekend, or a tab your browser restored days later, will have an expired sign-in behind it.

• You signed out somewhere else. Signing out of OnePass in any other tab or window signs this tab out too - the sign-in is shared across the whole browser.

• A one-off network hiccup. Occasionally a firewall or proxy between your computer and OnePass answers one request with an error page instead of a real answer, and Channel Studio can mistake that for being signed out. In this case you are actually still signed in, and simply trying the action again works.

Known bug: "View Channel" from the classic Screen Layout editor BUG - PRODUCT-1530

Two things to know about this case:

• Landing in Channel Studio after that click is normal and intentional - Channel Studio is now the default channel editor, so the old "View Channel" button takes you there (in a new tab). The bug is only the false session message, not the destination.

• The telltale sign is that the message appears moments after you arrive, typically with the channel list visible but the channel itself not opened. Follow the recovery steps below (usually just retrying works, since you are still signed in), and please report occurrences to support with the time it happened - each report helps pinpoint the server-side cause.

What to do - your work is not lost

1. Leave the Channel Studio tab exactly as it is.

2. Open a new browser tab, go to OnePass, and sign in as usual. (If OnePass shows you as already signed in, you were never really signed out - just go back and retry.)

3. Return to the Channel Studio tab (without refreshing it) and click Save again, or retry whatever you were doing. It now goes through, because the fresh sign-in is shared with that tab automatically.

When to contact support

If this happens repeatedly, or at times when you were clearly active just minutes before, let support know and include three details:

• The approximate time it happened.

• What you clicked right before the message appeared (for example "View Channel from the classic Screen Layout editor").

• Whether refreshing another OnePass tab showed you still signed in or sent you to the login page. This one detail tells us which cause to investigate.

For Technical Readers

How the studio detects "session expired"

All Channel Studio server communication goes through Scripts/channelstudio/api.js, which classifies every failed response into one of three shapes:

• Transport failure (offline, DNS, aborted) - shown as "Could not reach the server".

• Non-JSON body with HTTP status 200, 401, or 403 - shown as the session-expired toast discussed here.

• JSON body with {result:"error"} - a real application answer (access denied, channel not found, validation); the caller shows the specific server message instead.

The second shape is the signature of Forms Authentication rejecting the request: ChannelStudioController is [Authorize]-gated, so a request carrying a missing, expired, or undecryptable auth cookie is 302-redirected to the login page. fetch follows the redirect transparently and hands the studio the login page HTML with status 200; JSON.parse fails, and the toast is raised. All deliberate application errors return JSON, so this toast specifically means "the server no longer honored the authentication cookie" - or something upstream produced a response that looks exactly like that.

Authentication background

• OnePass uses Forms Authentication with a non-persistent cookie (a browser-session cookie; there is no "remember me" durability).

• The ticket lifetime is 2880 minutes (48 hours) with sliding expiration. A sliding ticket renews only when a request arrives after the halfway point of its life, so an idle tab loses authentication somewhere between 24 and 48 hours after the last server-hitting action.

• Channel Studio performs no background polling or keep-alive. Its only timer re-labels relative timestamps ("2 min ago") client-side every 30 seconds and never touches the network, so idle time counts in full against the ticket.

Possible causes, ranked

1. Server-side ticket invalidation (deployment, app-pool recycle, machine key)

Forms Authentication tickets are encrypted with the ASP.NET machine key. If that key is not pinned in configuration, or differs across load-balanced nodes, then a deployment, IIS app-pool recycle, or server reboot can make every outstanding cookie undecryptable at once - all active users get the toast on their next action, regardless of how recently they were active. Note that IIS's default periodic app-pool recycle interval is 1740 minutes (29 hours), which sits inside the 48-hour ticket window: an unpinned key on a default-configured pool would bounce users roughly daily. The telltale symptom is multiple users reporting the message at the same moment; correlate the report time with deployment logs and app-pool recycle events (Windows System event log, WAS/W3SVC recycle event IDs 5074-5081).

A variant of the same cause in a load-balanced farm: if two nodes carry different machine keys, a cookie minted by node A is rejected whenever a request happens to land on node B. Individual requests then fail while others succeed seconds apart - see the confirmed bug below, which shows exactly this signature.

2. Genuine idle expiry (24-48 hours)

A tab left open across a weekend, or a browser that restored its previous session days later (session restore brings back session cookies together with the tabs), carries a ticket past its sliding window. The first server-hitting action after the long idle - opening a channel, saving, renaming, uploading - triggers the bounce. Ordinary same-day idle (lunch, overnight) cannot expire a 48-hour ticket.

3. Signed out elsewhere

The auth cookie is shared browser-wide, so signing out of OnePass in any other tab (or clearing browser cookies) invalidates this tab's next request as well.

4. False positive: a non-JSON response from an intermediary

Because the detection rule is "non-JSON with status 200, 401, or 403 means session expired", any proxy, WAF, or maintenance page - or IIS itself answering with an HTML error page mid-recycle - is misreported as session expiry even though the ticket is still valid. In this case the user is still signed in and retrying the action simply works.

Confirmed bug (PRODUCT-1530): classic Screen Layout > "View Channel" repro

BUG This instance is acknowledged as a defect and tracked as https://kuusoft.atlassian.net/browse/PRODUCT-1530 : a signed-in user's request is falsely rejected as unauthenticated. The customer-reported repro, verified against the code (August 2026): open a layout in the classic Screen Layout editor, open a container's details, click View Channel - the toast appears shortly after Channel Studio loads. The chain works like this:

1. The "View Channel" button (_ContainerDetailInformation.cshtml) links to the classic editChannel action with target="_blank". The OnePass SPA's link interceptor deliberately skips links carrying a target attribute, so this is a real full-page navigation in a new tab.

2. Since Channel Studio became the default editor (OP-1400), editChannel without pv=true redirects to ChannelStudio/Index?key=&cguid=. Landing in the studio from this button is by design, not part of the bug.

3. The studio boots in a fixed order: it shows the channel list and calls GetChannels; only after that resolves does the ?cguid= deep link call GetChannel to open the editor. If GetChannel fails, the studio stays on the list.

That order makes the observed screenshot state - list fully populated + session toast + editor never opened - very informative. It means the [Authorize]-gated page load succeeded, GetChannels succeeded, and then GetChannel, sent seconds later with the same cookie, was bounced as unauthenticated. A genuinely expired ticket cannot do that: the same cookie was honored moments earlier. The failure is per-request, which narrows it to:

• Machine-key mismatch across load-balanced nodes (cause 1, farm variant). A new tab plus the studio's boot burst (page, static assets, two API calls) opens fresh TCP connections, which the load balancer may route to a different node than the long-lived classic tab's warm connections. Requests landing on a node with a different machine key are bounced; the rest succeed.

• An intermediary answering one request with an HTML page (cause 4).

Two more observations that fit: this entry path is close to the only common one that carries a ?cguid= deep link, so it is nearly the only path that fires the second (GetChannel) request at boot - the left-menu entry calls GetChannels alone and would show no toast when only the second request fails. And the classic pages suffer the identical per-request failure less visibly: their SPA injects the returned login page into the content area or navigates outright. The studio's toast is therefore likely surfacing a pre-existing intermittent authentication failure, not introducing a new one.

What to check server-side (also listed in PRODUCT-1530): machine-key parity across all nodes serving onepass.kuusoft.com (and that the key is pinned, not auto-generated); load-balancer stickiness configuration; then IIS logs on each node for the failing GetChannel request (a 302 to /Authentication/Login from an authenticated user's IP identifies the node that rejected the cookie). The ticket also notes a secondary client-side hardening option: a single silent retry of a bounced request before toasting.

Quick diagnosis

Why unsaved work survives (and how recovery works)

Channel Studio is a standalone page: all editor state lives in the page's JavaScript memory, and nothing about authentication failure destroys it. Cookies are per browser, not per tab, so signing in from a second tab re-arms the original tab's next request. Retrying Save after re-login therefore succeeds with no data loss. Only reloading or navigating away from the studio tab discards unsaved edits - which is exactly what the toast's wording warns about.