desktest.net
guide

SiteLink Test Guide

SiteLink Web Edition and myHub by Storable are the property management apps most self-storage facilities run at the front desk. This guide explains what the desktest.net SiteLink Test checks, how to read the verdict, and how to fix every failure mode it reports.

Open the SiteLink Test ->

What does the SiteLink Test check?

SiteLink Web Edition and myHub are pure browser apps: no Windows service, no signed applet, no loopback port. The test runs three steps. A hard Step 1 failure (unsupported browser, unsupported OS, or a missing core browser feature) stops the run there; otherwise the configuration and reachability steps both run so you see every remaining problem in one pass.

Step 1: browser meets the SiteLink support matrix

The page identifies the browser, the host OS, and probes the JavaScript engine for ES2017+ features. SiteLink's hardware page lists Chrome (preferred), Edge, Safari, and Firefox; Windows 10 or 11 (Pro or Home) as the supported desktop OSes. IE, legacy non-Chromium Edge, Windows 7, 8, 8.1, and Windows 10 S are out. Chrome, Edge, and Firefox 90+ and Safari 14+ are treated as current; older releases pass with a warning. TLS is implicit (the page only loads over HTTPS). The feature probe still runs on a recent-version report, so an outdated engine wrapped in a UA spoof fails on missing Promises, async/await, fetch, or window.isSecureContext.

Step 2: browser settings allow SiteLink to function

myHub needs first-party cookies (login session), popup windows (reports, receipts, eSign), and webStorage. The test round-trips a first-party cookie, opens and closes a popup from the Run click, and round-trips values through localStorage, sessionStorage, and IndexedDB. Any one failing is a hard fail: myHub uses all three storage layers, not just localStorage.

Step 3: SiteLink endpoints are reachable

A passive no-cors fetch is sent to myhub.sitelink.com. It resolves on a successful TCP + TLS handshake and rejects on DNS, firewall, or certificate failure. The response is opaque, so the test cannot read a status code: "the host answered" is the best it can claim. The test then opens myhub.sitelink.com in a new tab and asks you to confirm the login form rendered. The human confirmation is the authoritative signal.

When should I run this?

Reading the results

Each row shows a badge: PENDING, RUNNING, PASS, FAIL, WARN, or MANUAL. Failed rows expand automatically with sub-check details and a fix block. MANUAL appears only on the reachability row when you skip the guided confirmation.

When all three rows finish, a verdict card appears with two fields. Likely cause names the diagnosis (unsupported-browser, unsupported-os, missing-features, stale-version, a list of failed configuration checks, or a reachability error). Recommended next step gives one concrete action; the expanded row has the full procedure.

The ping step is passive: a no-cors fetch cannot read a status code and cannot detect a TLS-intercepting proxy, so it cannot 100% verify reachability. The visual confirmation in the new tab is authoritative. If you confirm the login page rendered but the ping failed, the test records PASS with a note.

Copy Diagnostic Report copies a plain-text summary to your clipboard: timestamps, browser, engine, OS, user agent, origin, per-step status, diagnosis code, feature grid, configuration sub-checks, ping result in ms, and your reachability confirmation. Paste it into a Storable ticket. No tenant data, facility identifiers, or credentials are included.

Common failures and fixes

Cookies disabled

The first-party cookie probe failed: either navigator.cookieEnabled is false, or the cookie did not read back. Re-enable cookies for sitelink.com and smdservers.net. In Chrome / Edge: Settings -> Privacy and Security -> Cookies -> Sites that can always use cookies, then add [*.]sitelink.com and [*.]smdservers.net. In Firefox: Settings -> Privacy and Security -> Cookies and Site Data -> Manage Exceptions.

Third-party cookie restrictions

navigator.cookieEnabled stays true when only third-party cookies are blocked, which is why the test round-trips a real cookie. SiteLink embeds receipt and eSign iframes from related domains; aggressive blocking breaks them. In Chrome / Edge, allow third-party cookies for SiteLink sites. In Firefox, set Enhanced Tracking Protection to Standard (not Strict) for these sites.

Popup blocker

The test calls window.open() from the Run button's click handler. If the result is null or closes instantly, the popup blocker rejected it. Whitelist myhub.sitelink.com and www.sitelink.com:

localStorage disabled

The localStorage write threw, usually because the tab is in private / InPrivate / Incognito. Safari Private Browsing throws QuotaExceededError on the first write; Chrome Incognito and Edge InPrivate isolate storage to the tab. Re-open in a normal window. If you are not in a private session, check the site-data setting for SiteLink: a "block all data" override defeats localStorage too.

IndexedDB disabled

The IndexedDB open errored, was blocked, or did not resolve inside three seconds. Firefox Strict ETP can silently hang IndexedDB on third-party origins; the three-second guard catches that. Switch ETP to Standard for SiteLink, or exit private browsing.

Firewall blocking SiteLink hostnames

The ping rejected and you confirmed the login page failed. Ask your network admin to allow these outbound on 443:

myhub.sitelink.com
www.sitelink.com
mysitelink.com
*.smdservers.net

SiteLink uses smdservers.net for static assets and API endpoints; allowing only the sitelink.com hosts leaves the login page half-loaded.

TLS handshake failures on legacy Win7

Rare in 2026. SiteLink's edge requires TLS 1.2 with modern ciphers. Windows 7 without SChannel updates fails the handshake before HTTP is spoken. Windows 7 is off Storable's support list and out of Microsoft support: replace the OS.

Browser too old

The browser was flagged as missing-features (hard fail) or stale-version (warning). Update to the current stable channel: Chrome via chrome://settings/help, Edge via edge://settings/help, Firefox via about:preferences -> General -> Firefox Updates.

For IT admins

Configure browsers centrally via GPO and stop fixing the same setting on every workstation.

Allow popups on SiteLink domains. Push PopupsAllowedForUrls in Chrome and Edge:

HKLM\Software\Policies\Google\Chrome\PopupsAllowedForUrls
HKLM\Software\Policies\Microsoft\Edge\PopupsAllowedForUrls
  1 = "https://myhub.sitelink.com"
  2 = "https://www.sitelink.com"
  3 = "https://[*.]sitelink.com"

For Firefox, use autoconfig or Enterprise Policies JSON with a Permissions.Popups.Allow array.

Allow third-party cookies on SiteLink domains. CookiesAllowedForUrls in Chrome and Edge, same list plus [*.]smdservers.net.

Whitelist in the content filter. Add sitelink.com, mysitelink.com, and smdservers.net to the outbound allow list. If the filter does SSL inspection, add a bypass for these hosts.

Push a managed bookmark. Use ManagedBookmarks in Chrome and Edge to pin https://myhub.sitelink.com/ to the bookmarks bar.

Behind the scenes

The whole test runs in your browser tab. No localhost service, no driver, no installer. Browser detection reads navigator.userAgent and navigator.userAgentData when present, plus feature probes wrapped in try/catch. The configuration step uses document.cookie, calls window.open() once during the Run click (browsers grant one popup per user gesture), and exercises localStorage, sessionStorage, and IndexedDB. The reachability step uses fetch() with mode: 'no-cors': enough to confirm TCP+TLS, not enough to read the body. The guided confirmation calls window.open() a second time inside its own click handler, after a user gesture.

Nothing is sent anywhere except the single no-cors ping to myhub.sitelink.com: the same request your browser would make if you typed the URL. SiteLink, SiteLink Web Edition, and myHub are trademarks of Storable. This site is unaffiliated.