jcoffey-dev
82470e8db0
ihasmail could hand a file to the share sheet as of #306, and was still not in it. Share a photo from the gallery, a link from the browser or a document from a file manager and ihasmail was not among the places it could go, which is the one piece of operating-system integration a mail app is expected to have. A share is a POST that navigates, and there is nothing on this side that can answer one: the app is a client-side router with no endpoint at that address, and the server behind it would need a route that understood the composer. So the service worker intercepts it, takes the form body, puts the files and text in its cache, and redirects to the app -- which finds them on start and opens a draft holding them. The subject is the shared title, the text and the link become the body, and files are attached and begin uploading. Nothing is addressed: a share says what to send, never who to. The body is pushed in above the signature rather than passed to open(), because open() only fits a signature when it is given no body at all -- the obvious version drops the signature from every message that started as a share, and nothing about the draft looks wrong afterwards. Collected on every start rather than when the launch URL says so. A share to a signed-out ihasmail lands on the sign-in page, and there is no account to attach to until it is done, so the payload has to outlive a redirect and a login -- which the query string does not. What that costs is a stash nobody came back for, so it carries a timestamp and expires after ten minutes. `accept` names wildcard families and explicit types and extensions both. A mail client attaches anything, but wildcards are not in the specification and operating systems differ over which form they match on, so the explicit list is what holds if the families are ignored. The cache name the worker and the app have to agree on now has one home on the app side. It was written out twice, and a drift would not fail -- a push verification would simply never complete and a share would arrive at an empty composer. One case is deliberately left to fail loudly: an app still installed whose worker has been cleared away POSTs to the server, which answers 405. A server route would trade a plain error for a silent nothing, and the payload is gone in both -- it only ever existed in that request body. Verified by test, not on a device: Android is the only place this exists at all, and the extension driving Chrome is not connected here. The handoff is pinned from the tab's side against a cache shaped exactly as the worker leaves it, since the two files never see each other.
15 lines
637 B
TypeScript
15 lines
637 B
TypeScript
/**
|
|
* The name of the cache the service worker keeps.
|
|
*
|
|
* It is `VERSION` in `web/public/sw.js`, and the worker is not built from this
|
|
* source -- it is copied to `dist` verbatim, so nothing checks that the two
|
|
* agree. They have to: the worker uses that cache to leave things for a tab to
|
|
* collect when there was no tab to hand them to, and a name that has drifted
|
|
* does not fail, it silently finds nothing. A push verification never
|
|
* completes; a share arrives at an empty composer.
|
|
*
|
|
* One copy on this side of the line, so at least the app cannot disagree with
|
|
* itself.
|
|
*/
|
|
export const SW_CACHE_NAME = "ihasmail-v2";
|