Skip to main content

Cookies & Browser Storage

A browser can retain sign-in state so a person can continue working after authentication. Storing a complete session token in one place would make a copy of that store sufficient to recover the credential. The main Files.com web interface instead splits its saved session token between a cookie and local storage.

Split Session Storage

After sign-in, the web interface saves one half of the session token in a session cookie and the other half in origin-scoped local storage. It associates the two parts so it can find the matching pair when restoring the session.

Neither store contains the complete token. Copying only the cookie or only local storage is insufficient to recover the saved session credential. Clearing either part prevents the application from restoring that saved session on a subsequent page load.

The application combines the matching parts in memory and explicitly supplies the complete token in an API request header over HTTPS. The browser sending the cookie alone does not authenticate those requests.

Both stored parts are accessible to JavaScript running in the application's origin, and the complete token exists in memory while the application uses it.

The split protects against disclosure of either store alone; it does not prevent code already running inside the application from using its session. Content rendering and script restrictions remain essential controls.

The completed web-interface sign-in saves the cookie with the Secure attribute, which restricts its transmission to HTTPS. The browser's origin rules limit which website can read the local-storage part.

The application must read the cookie to combine the parts, so this cookie is not HttpOnly.

Cookie attributes have different jobs. HttpOnly controls script access to a cookie; SameSite controls when it accompanies requests from another site. Neither attribute controls access to all browser storage, erases downloaded files, or replaces authorization for a request.

Sharing and Hosting Credentials

The split described above applies to the main web interface's saved sign-in. Share Link visitors have separate access determined by the link's requirements and allowed actions. Their visitor credentials do not grant ordinary Site access.

Public Hosting with Site login uses a separate Secure, HttpOnly cookie with SameSite=Lax on the hosting hostname. It does not give hosted content the main web interface's session token or move that content into the application's origin.

Storage and Session Lifetime

The Site's Session Expiration controls expiration after inactivity. Desktop App and Mobile App session lifetimes are separate settings; they do not define the lifetime of a browser sign-in.

Storage of sign-in state does not keep an invalidated session valid. Re-authentication, Password Recovery & Credential Changes, and Access Revocation explain the server-side checks and effects of sensitive changes.

Shared Devices and Information Already Received

A browser profile can retain cookies, storage, previews, and downloaded files. Browser extensions and software controlling that profile can also affect the application's operation. Use a managed browser profile and end the session when another person will use the device.

Signing out or invalidating the session governs subsequent authenticated use. It cannot retrieve files already downloaded or erase information previously displayed. A temporary transfer URL already issued has its own expiration, as described in Downloads Already Authorized.