v1.34.0

The widget now expires its own token. Browser-side only — no server change, no API change.

Added

Token expiry, and expiredCallback finally fires.

All three servers reject a token older than 300 seconds. The widget did not know that. The checkbox went on showing "verified" long past the point the token would be accepted, so a form left open for five minutes failed on submit — and the integrator had no way to know why.

expiredCallback has been in the public options object since the first release. It was invoked nowhere.

Now, when a token reaches the end of its useful life, the widget:

• resets itself to the unverified state
• drops the stale token, so getToken() stops handing back something the server will refuse
• calls expiredCallback()
• dispatches a fcaptcha:expired event on the container

FCaptcha.render('captcha', {
  siteKey: '...',
  callback: function (token) { submitButton.disabled = false; },
  expiredCallback: function () {
    submitButton.disabled = true;   // now actually runs
  }
});

Or via the event:

document.getElementById('captcha')
  .addEventListener('fcaptcha:expired', () => { /* … */ });

Two details worth knowing. Expiry fires slightly before the server-side lifetime rather than exactly on it, so a form submitted right on the boundary is not refused by a token the checkbox still showed as good. And a manual reset() cancels the pending expiry, rather than reporting one afterwards for a state the integrator has already handled.

Upgrading

Nothing to change. If you never set expiredCallback, the visible difference is that a long-idle widget returns to its unverified state instead of displaying a checkmark backed by a token the server would reject — which is what it should have done all along.