WeDispatch 1.6.1: the lock now covers the file, and pages load faster
Restricted access now protects the audio file itself, not just the page that presents it. Together with the fixes from our performance report.
A consolidation release, with no new visible feature: it strengthens how restricted content is protected, and shortens how long public pages take to appear.
The access lock moves down to the file
A publisher who reserves articles for registered readers or subscribers counts on us for two things: that the page will not hand full playback to an anonymous visitor, and that the file itself cannot be reached another way. The first was already in place. The second now is too.
For a client with conditional access, the full article, its word timings and its summary now live in private storage. They are served only through a signed link, valid for two hours, issued to a visitor who is entitled to it, and to nobody else. The free excerpt stays public: it is what we deliberately give to anonymous visitors, and keeping it that way lets the podcast feed keep working with no change on your side. For a client with open access, nothing moves: there is nothing to protect.
The sorting happens file by file, automatically, both when audio is generated and when it is corrected. And when a signed link cannot be produced, the player never falls back to an open address: it shows its waiting state instead. Nine automated checks pin this rule down and prevent it from quietly loosening later.
Background work opens only with a key
The queue that picks up pending jobs now accepts two credentials and no others: the operations secret passed as a header, and the signature our host applies to its own scheduled jobs. Two checks stand guard, one re-reads the code on every change, the other queries production and confirms that it refuses everything else.
Pages that appear faster
We went through our performance report and fixed everything that could be fixed without a trade-off.
Demonstration videos and illustrations now carry a one-month cache instruction: a returning visitor no longer downloads them again. The embedded player deliberately gets a short cache, its address is fixed and it runs on your site, so a long cache would freeze a fix across every installation.
Audience measurement has been split in two: a few hundred bytes of bootstrap played early, and the full library deferred until after the page has rendered. The video posters moved to a more compact image format, since they are the first thing painted on the home page. The filter that sits in front of pages no longer runs in front of every image, file and interface call. And the first French page a visitor sees no longer writes a language cookie to confirm a setting that was already in effect, that seemingly harmless write was keeping our most-visited pages out of the shared delivery cache.
One item was measured and then set aside: targeting a more recent list of browsers saved a single byte once compressed, and cost compatibility with several versions of Safari still in circulation. That was not a trade we wanted to make.
A few quiet tightenings
The redirect parameter on the sign-in screen now accepts internal destinations only. Accepting an invitation requires a confirmed email address, which makes that guarantee independent of a console setting. The address of an article discovered in an RSS feed passes the same network filter as webhooks before being fetched. And the technical responses from our internal routes are now explicit projections that carry only what they need to carry.
The WordPress plugin moves to 1.9.1: the "manual" mode saved from the settings screen is now correctly kept (it used to revert to automatic, and therefore to billed narration) and token retrieval works again on sites served from a cache.
What this changes for you
If you use the WordPress plugin, update it: the manual-mode fix prevents narration you did not ask for. Everywhere else no action is required, your settings, your voices, your integrations and your public file addresses are unchanged.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo