Sign inRegisterCheck connection

Mobile Sessions Versus Desktop Cookies on a Weather CMS

Mobile weather-CMS sessions differ from desktop cookies: smaller storage, stricter jars, and easier logout. This URL explains that problem; it is not a sign-in form.

Back to Cumulus weather software guides

/m&action=login is the historical mobile CMS login mode: the query string a small-screen skin used when it needed a session. It is not the mobile site root, not a forecast tab, and not an About-page membership gate. Those URLs have other jobs. This one is about staying logged in on a phone—how mobile cookie jars differ from desktop ones, and why a tiny weather CMS kept losing sessions.

There is no form here. TNET does not restore member accounts, password reminders, or a working cookie. Gallery and About &action=login twins, if they exist in this footprint, are about those sections’ access. /m&action=login is the mobile session problem only.

Historical context

Desktop weather CMS installs used PHP sessions (PHPSESSID or a renamed cookie) plus optional “remember me” cookies for operators who edited templates from a home PC. The mobile skin reused the same account table with a different template: /m for the public root, /m&action=login (or /m/?action=login) for the gate. Feature phones and early smartphones did not treat that cookie the way Internet Explorer on a tower PC did.

WAP gateways sometimes stripped or rewrote cookies. Built-in browsers capped cookie count and size. Shared family phones mixed users. Private browsing dropped the session when the overlay closed. Operators described this as “the mobile site keeps logging me out.” The cause was storage policy, not a mysterious Cumulus bug.

The original login script is not rehosted. HTTP cookies are specified in RFC 6265 (last checked 13 August 2026). PHP’s session module is documented in the PHP session manual (last checked 13 August 2026). This page uses those public contracts. It does not describe TNET’s modern dashboard authentication.

What a session is on a small CMS

A session is a server-side record keyed by an identifier the browser presents. For PHP, that identifier is usually a cookie. The weather CMS then decides whether the client may see a gated gallery, an edit screen, or a “member” note. Public observations—the /m root—should not have required a session at all. Mixing “must log in to see temperature” with “must log in to edit the template” is how a station disappeared from phones.

Keep three objects separate:

  1. Public observation — GET, no account. /m is this product.
  2. Operator session — edit, upload, gated renderers. This URL’s subject.
  3. Visitor preference — units display, theme. A preference cookie is not an account. Do not promote it to a login wall.

Graph galleries that used login to stop hotlinking are a renderer problem (/graphs&action=login). They should not have required the mobile observation root to carry the same cookie. A phone that only wanted “now 21°C” should not have been bounced through /m&action=login.

How mobile jars differ from desktop jars

Count and size. RFC 6265 requires clients to support at least 50 cookies per domain and 4096 bytes per cookie, but embedded browsers and older phones often stored less. A CMS that set a session cookie, a remember-me cookie, a unit preference, a theme, a banner-dismiss, and a gallery token could evict the session first. Desktop PCs hid the problem.

Host and path. Cookies are scoped by host and path. A session set on cumulus.tnetweather.com/ might not be sent to /m if the CMS set Path=/graphs. Mobile skins that lived under /m needed Path=/ or Path=/m deliberately. Accidental path scope looked like “mobile login is broken.”

Secure and scheme. A cookie without Secure set on HTTPS may still be sent later on HTTP, or the reverse mix may drop it. Early mobile users hit http:// bookmarks after an operator enabled TLS. The desktop bookmark had been updated; the phone bookmark had not.

Gateway and WAP. Intermediaries that fetched WML might not forward Set-Cookie. That is one reason /wap.php should have been a public observation deck. Putting &action=login on a WML bookmark was a category error. /m&action=login assumed an HTML cookie jar; it still failed when the jar was the carrier’s proxy.

Private mode and storage eviction. Phones reclaim storage aggressively. A “stay logged in” cookie with a far-future expiry is still disk. When the OS evicts it, the operator thinks the CMS expired the session. Document a short server-side lifetime that matches what a phone will actually keep, rather than promising thirty days.

Shared devices. A kitchen-table phone used for “check the station” is not a private workstation. Persistent operator cookies on /m turn every house guest into an editor if the CMS did not separate roles. Desktop CMS culture assumed one user per PC. Mobile CMS culture cannot.

Staying logged in without a fake “remember me” theatre

Honest patterns for a small station CMS (conceptual; not a recipe to copy old PHP):

  • Do not require a session to read observations. If the mobile root needs a login, the product is wrong.
  • Short-lived operator sessions with re-auth for destructive actions (template upload, password change).
  • SameSite and CSRF on any POST that changes station files. A cookie that is sent on every GET is not a complete defense.
  • No credentials in the query string. &action=login as a mode name already leaked into archives; &password= must never join it.
  • One cookie name, documented. Do not set PHPSESSID on desktop and MOBILESESS on /m unless you intend two sessions. Dual cookies double eviction risk.
  • HTTPS everywhere for any authenticated path. Mixed-content mobile browsers will drop or isolate cookies.

TNET’s restored pages do not implement these controls. They are the rules a historical &action=login URL should have been teaching instead of drawing a password box.

Distinct from neighboring login strings

| URL | Distinct job | |---|---| | /m | Public mobile root | | /m&action=login | Mobile session storage (this page) | | /m/forecast | Forecast view, no account | | /graphs&action=login | Gate on the first graph renderer | | /graphs2&action=login | Gate on a second/versioned collection | | About-page &action=login twins | Section membership / about-CMS identity, not the /m jar |

If two login URLs cannot be distinguished, they should be flagged—not cloned. This pair is distinguishable: observation skin versus graph directory versus about-section identity.

Practical checklist

  • Public /m remains GET-only for observations.
  • Operator session cookies are scoped on purpose (host, path, Secure).
  • No login form is published on restored historical URLs.
  • Query strings do not carry passwords.
  • Shared-phone risk is treated as a design input, not an afterthought.
  • WAP decks stay public measurements, not member gates.

TNET research bridge

A session cookie is not an observation. Confusing “logged in” with “the temperature is valid” is an evidence-family error. TNET’s public vocabulary for observed versus derived information is how the service works. Source freshness for the files a mobile root would display is data sources, quality controls, and methodology.

The Cumulus hub lists related historical pages. Use /m if you wanted the mobile product, not a gate.

Sources