[updater] `check()` fails on private repos due to wrong header

[SimenZhor]

Hi,

I'm trying to implement a closed-beta updater feature for my app, and just ran into a problem caused by the check() function overwriting my manually written headers.

---

Background

Since I'm connecting to a private repo, I'm using a GitHub API endpoint instead of the direct URL to latest.json. And the API for getting a release asset is a bit funky. If the Accept header is set to application/vnd.github+json (which is considered "normal use" by the API, I believe), GitHub will return metadata about the asset - not the actual asset itself. So when using the API to download latest.json the Accept header needs to be set to application/octet-stream instead.

Exact description in the GitHub REST API docs:

To download the asset's binary content:

• If within a browser, fetch the location specified in the browser_download_url key provided in the response.
• Alternatively, set the Accept header of the request to application/octet-stream. The API will either redirect the client to the location, or stream it directly if possible. API clients should handle both a 200 or 302 response.

---

The problem

I'm building an Updater object using the UpdaterBuilder so that I can supply the correct endpoint and necessary headers.

let updater = app
        .updater_builder()
        .endpoints(vec![url])?
        .headers(headers)
        .build()?;

When I later call updater.check()

if let Some(update) = updater.check().await? {
    // [...]
}

I get an error that updater failed to deserialize the update response:
[2025-04-10][15:41:39][tauri_plugin_updater::updater][ERROR] failed to deserialize update response: unexpected character 'l' while parsing major version number

The reason Updater can't parse the json file is because it's actually working on the json file containing metadata about the asset, and not on the latest.json itself (verified by setting log-level to TRACE and looking at the console output). I'm almost certain that this is caused by check() injecting the aforementioned Accept header here setting it to application/json. I assume there are two Accept headers in the outgoing request, but that the GitHub backend decides to go with the one injected by check().

---

Appendix: Updating from private repos

Since I've been wrangling with these headers for a while now, I thought I'd write down the process for accessing a private asset through the GitHub API, as I'm sure someone will come across this issue working on a similar problem.

1. Download metadata about the latest release from https://api.github.com/repos/{owner}/{repo}/releases/latest using the following headers:

use reqwest::header::{HeaderMap, ACCEPT, AUTHORIZATION, USER_AGENT}; 

let mut headers = HeaderMap::new();
headers.insert(ACCEPT, "application/vnd.github+json".parse()?);
headers.insert(USER_AGENT, "my-tauri-app".parse()?);
headers.insert(AUTHORIZATION, format!("Bearer {}", PRIVATE_REPO_TOKEN).parse()?);

2. Parse the metadata json and look for the asset containing your latest.json. Extract the url field from here and use it in the next step. It should look something like this: "url": "https://api.github.com/repos/{owner}/{repo}/releases/assets/805105863"
3. Downoad the asset using the url found in the previous step. This time you need a different Access header, like mentioned before:

use reqwest::header::{HeaderMap, ACCEPT, AUTHORIZATION, USER_AGENT}; 

let mut headers = HeaderMap::new();
headers.insert(ACCEPT, "application/octet-stream".parse()?);
headers.insert(USER_AGENT, "my-tauri-app".parse()?);
headers.insert(AUTHORIZATION, format!("Bearer {}", PRIVATE_REPO_TOKEN).parse()?);

4. GitHub also recommends adding a header to specify the API Version you are integrating against. Everything works fine without this header at the time being, so I didn't insert it in the steps above for readability. But here it is anyway:

use reqwest::header::{HeaderMap, HeaderName, ACCEPT, AUTHORIZATION, USER_AGENT}; 

// Optional header that is recommended by GitHub
let hdr = HeaderName::from_lowercase(b"x-github-api-version")?;
headers.insert(hdr, "2022-11-28".parse()?);

[SimenZhor]

I got check() working by replacing

// we want JSON only
let mut headers = self.headers.clone();
headers.insert("Accept", HeaderValue::from_str("application/json").unwrap());

with

// Make sure `self.headers` contains an `Accept` header
let mut headers = self.headers.clone();
if headers.get("Accept").is_none() {
    headers.insert("Accept", HeaderValue::from_str("application/json").unwrap());
}

But that made me realize downloading from the URLs specified in latest.json won't work from a private repo as they need to be fetched through the API using the same mechanism as described in the appendix of my issue (first downloading release metadata, then fetching the binaries using the relevant asset URLs).

I guess it would be possible to solve this as a step in check() that's triggered by finding an Authorization header in headers. The logic could look something like this:

1. If Authorization in headers and endpoint on format "https://github.com/{owner}/{repo}/releases/{version}/download/latest.json"
2. Replace "github.com" with api.github.com and remove "/download/latest.json"
3. Download release metadata (let's call it release.json).
4. Find latest.json asset in release.json
5. Download latest.json using the value specified in the url field of the asset
6. For each target in latest.json, match the url value from latest.json against browser_download_url values in release.json and replace them with the corresponding url (from the same asset in release.json).

It's not super elegant, and maybe a bit too GitHub specific? Any thoughts on adding such a feature?

[FabianLars]

It's not super elegant, and maybe a bit too GitHub specific? Any thoughts on adding such a feature?

This was discussed a few times already and I'm still against it though I don't think the rest of the team ever voiced their opinions.

It should be fairly straightforward to do the initial request via reqwest or fetch and then pipe the new endpoint url into the updater and the new asset url into the Update struct.
There should be an example of this either here or on discord iirc. Can't find it right now but your writeup is probably better anyway.

P.S. I'm not saying "never" but we have the tendency to add new features before the base functionality is actually working well and I keep trying to prevent that.

[SimenZhor]

That's totally fair, and I knew that my approach would probably be a bit too specific for my needs to be implemented.

Another option could maybe be to implement a setter method foo the download_url, so that the url-matching logic can be done in the main app instead of in this library (after calling check() but before calling download()). Then, the only modifications to the updater plugin should be to prevent overwriting Accept headers and enabling explicit user-overrides of the download_url.

I'm not sure if this would open up any safety concerns that I'm not considering.

[FabianLars]

Another option could maybe be to implement a setter method foo the download_url, so that the url-matching logic can be done in the main app instead of in this library (after calling check() but before calling download()).

This is supposed to work (if not then it's a bug). check() returns an instance of Update which you can modify as you see fit before calling its download method.. May only be possible in Rust, can't remember the plugin's js api

[SimenZhor]

You are right, it does work :) I'm new to Rust, so I guess I misread something.

Anyway, then I guess I'm back to square one and the original issue I submitted. Would you be OK with the solution I proposed here? If so, I can submit a PR.

[FabianLars]

yeah, that approach should be fine. prs are always much appreciated :)

[Legend-Master]

I'm just trying that an hour ago (#2621), and I feel like maybe there're some reworks we need to do around the rust APIs, things inherit in a really weird way (that's why I didn't open the PR yet, but since we're at it, let's just fix the issue first)

Love your issue write up by the way

[SimenZhor]

I'm just trying that an hour ago (#2621)

Oh, awesome. I'll leave it to you then!

Since you're in there doing modifications already, you might want to consider giving the User Agent header a similar treatment:

plugins-workspace/plugins/updater/src/updater.rs

Line 392 in c698e72

let mut request = ClientBuilder::new().user_agent(UPDATER_USER_AGENT);

[Legend-Master]

Since you're in there doing modifications already, you might want to consider giving the User Agent header a similar treatment:

I think the headers will override it here?

plugins-workspace/plugins/updater/src/updater.rs

Line 409 in c698e72

.headers(headers.clone())

[SimenZhor]

You're right, thanks for getting the PR ready so fast, I really appreciate it! 😀