Publish New Versions (v2)

[github-actions]

Version Updates

Merging this PR will release new versions of the following packages based on your change files.

api-example

[2.0.49]

Dependencies

• Upgraded to http@2.7.0
• Upgraded to log@2.9.2
• Upgraded to updater@2.12.0

api-example-js

[2.0.45]

Dependencies

• Upgraded to log-js@2.9.2
• Upgraded to updater-js@2.12.0

http

[2.7.0]

• 1198a52 Security: Added the scopeRedirects plugin configuration option, which checks the URL scope on every hop of a redirect chain instead of only on the URL requested by the frontend. Without it, a server on an allowed origin can redirect the request to any other origin - including localhost services, internal hosts and cloud metadata endpoints - and the plugin follows it, returning the response to the webview.

  {
    "plugins": {
      "http": {
        "scopeRedirects": true
      }
    }
  }

  It is opt-in because a redirect to a URL that is not allowed by the scope now fails with url not allowed on the configured scope instead of being followed, so applications that rely on being redirected outside of their scope must add the redirect target to the scope. This will become the default in v3.

  Note that tauri_plugin_http::init() now returns TauriPlugin<R, Option<Config>> instead of TauriPlugin<R>.

log

[2.9.2]

• 2df3d93 (refactor(log): log webview location after double colon #3574) Log webview log target locations after 2 colons instead of 1. (e.g. webview:myFunction@http://localhost:5173/src/myFile.ts?t=1787480723620:47:4 to webview::myFunction@http://localhost:5173/src/myFile.ts?t=1787480723620:47:4)

log-js

[2.9.2]

• 2df3d93 (refactor(log): log webview location after double colon #3574) Log webview log target locations after 2 colons instead of 1. (e.g. webview:myFunction@http://localhost:5173/src/myFile.ts?t=1787480723620:47:4 to webview::myFunction@http://localhost:5173/src/myFile.ts?t=1787480723620:47:4)

single-instance

[2.4.5]

• 67cd25a (fix(single-instance): let the first instance come to front on Windows #3592) On Windows, the second instance now allows the first instance to bring its window to the front before exiting, so focusing a window from the callback no longer gets refused by Windows.

updater

[2.12.0]

• 1308bfa Breaking change: the allowDowngrades option was removed from the check command and is now read from the plugin configuration instead.

  Previously any code running in the webview could pass allowDowngrades: true to plugin:updater|check and relax the version check from "the update must be newer" to "the update must be different", overriding the comparator the application had configured on the Rust side. The flag is now an application-level setting:

  {
    "plugins": {
      "updater": {
        "allowDowngrades": true
      }
    }
  }

  It defaults to false, and is ignored when the application provides its own Builder::default_version_comparator, which continues to take precedence.

• 690dcfd Add a requireSignedVersion configuration option that binds an update to the version it was signed for.

  The update endpoint response is fetched over TLS but is not itself signed, and the signature only covers the downloaded artifact. Anyone able to serve a crafted response could therefore pair an inflated version field with the url and signature of an older release and force a downgrade to a genuine but outdated build, because that older artifact carries a valid signature.

  The Tauri CLI records the version in the signature's trusted comment, which the signature covers. With this option enabled the updater compares that signed version against the one announced by the endpoint and rejects the update when they differ:

  {
    "plugins": {
      "updater": {
        "requireSignedVersion": true
      }
    }
  }

  It defaults to false because releases signed before the CLI started recording the version carry none and would be rejected. Re-sign and re-publish every release your users can still update from before enabling it, otherwise an older signature can still be served to bypass the check. When the signature does carry a version, a mismatch is rejected whether or not the option is enabled.

  This is checked independently of allowDowngrades: it constrains which artifact a given version number may resolve to, not whether that version is newer than the running one.

updater-js

[2.12.0]

• 1308bfa Breaking change: the allowDowngrades option was removed from the check command and is now read from the plugin configuration instead.

  Previously any code running in the webview could pass allowDowngrades: true to plugin:updater|check and relax the version check from "the update must be newer" to "the update must be different", overriding the comparator the application had configured on the Rust side. The flag is now an application-level setting:

  {
    "plugins": {
      "updater": {
        "allowDowngrades": true
      }
    }
  }

  It defaults to false, and is ignored when the application provides its own Builder::default_version_comparator, which continues to take precedence.