Suite sign-in and cookie domain (*.waryway.com)

One suite, shared auth family

Waryway products live under related hostnames: the hub at waryway.com, app subdomains such as Scrumbets and Retronium, guides at guide.waryway.com, and sign-in at auth.waryway.com.

Auth is centralized. Suite pages can open a sign-in modal that talks to the auth service, or you can visit auth directly. After a successful login, browsers hold a session cookie scoped for the waryway.com family so signed-in state can apply across those suite hosts—not as separate accounts per app.

What you should expect when signing in

1. Start from a suite page or auth. On the hub (and many suite apps), use Sign in in the chrome. That posts credentials to the auth origin with credentials included—no separate popup window required on the primary path.
2. Complete login on auth. Create an account or sign in. Auth may also offer a standalone login page at auth.waryway.com if you navigate there directly.
3. Return to the app you care about. After success, go back to (or stay on) the hub or product host—Scrumbets, Retronium, Paint on the hub path, guides, and so on. Signed-in UI (user menu, identity chips) should reflect the same account when the browser still has the suite session cookie.
4. One account family, many destinations. You are not expected to re-register per app. Destination apps remain separate products; they share the auth cookie family, not a single merged UI.

Cookie domain in plain language

Browsers attach cookies only to matching hosts. Production auth sets a session cookie (named for the suite token) with domain .waryway.com so hosts under that parent can receive it on later requests—hub, subdomains, and auth itself.

• Same family. scrumbets.waryway.com and waryway.com sit in the same parent-domain cookie family. That is why one successful sign-in can cover multiple suite apps in the same browser.
• Credentials matter on cross-origin calls. Suite frontends talk to auth with credentials included. Auth allows browser origins that are waryway.com, www.waryway.com, or hosts ending in .waryway.com—so normal suite pages are expected; random third-party sites are not.
• SameSite is ordinary browser policy. Session cookies use standard SameSite lax-style behavior appropriate for top-level navigation and same-site suite use. You do not need special browser flags for everyday suite sign-in.

Local development may use host-only cookies or non-secure flags when running auth in dev mode. This guide focuses on the production *.waryway.com experience users hit on the public suite.

Why the wrong origin breaks the session feel

“I signed in, but this tab still looks signed out” is usually an origin or browser-context mismatch, not a forgotten password. Common cases:

• Different site entirely. A bookmark to an IP, a preview host, or a non-waryway.com clone never receives the suite cookie. Sign-in on auth does not magically attach to unrelated domains.
• http vs https or odd ports. Production suite is HTTPS on the real hostnames. Mixing schemes, tunnels, or custom ports can leave you on a host that is not in the cookie domain family the way production is.
• Separate browser profiles / private windows. Cookies do not jump profiles. Incognito and normal windows keep separate stores—sign in again in the window you actually use for the app.
• Incomplete sign-in. Closing the modal mid-flow or failing validation never sets the session cookie. Finish the login step on auth, then return to the product tab and refresh if the chrome still looks empty.

Practical tips

1. Use suite domains. Prefer https://waryway.com, https://auth.waryway.com, and known *.waryway.com app hosts—not copies or unknown mirrors.
2. Complete sign-in on auth. Whether you use the hub modal or the auth site, wait for a successful login response before judging whether other tabs are signed in.
3. Return to the app, then refresh if needed. After auth, open the product you meant to use. If chrome still shows Sign in, reload once so the page re-reads the session cookie.
4. Stay in one browser profile. Jumping between profiles, containers, or strict third-party cookie blockers can make the suite feel inconsistent even when the password was correct.
5. Sign out from the suite when you mean it. Use the product’s sign-out / auth logout path so the session cookie is cleared for the family, not only a single tab’s UI state.

FAQ

Do I need a separate account for Scrumbets and Retronium?

No. Suite apps share the same auth family. Create one account via auth / hub sign-in; use it across suite destinations in the same browser.

Is the cookie visible to every website?

No. The production cookie is domain-scoped to the waryway.com family. Ordinary other sites do not receive that suite session cookie.

Why can I open Paint without signing in?

Some tools (for example browser Paint) work without an account for core drawing. Sign-in still uses the same suite auth when a surface offers identity chrome; lack of a gate on a free tool is not a broken cookie.

Does CORS mean anyone can call auth from anywhere?

Auth allows browser origins that are part of the Waryway host family (apex and *.waryway.com). That is how suite pages call login with credentials—not an open invitation for arbitrary third-party sites.

Where do I go if I only want to sign in?

Start at https://auth.waryway.com or use Sign in on https://waryway.com.

Try it

Related guides

• Host a Scrumbets room: first-run checklist — open a suite app room after you sign in once on *.waryway.com.
• Planning poker facilitation for remote teams — run estimation on Scrumbets with the same suite session.