sanity-io / sanity-plugin-mux-input

An input component that integrates Sanity Studio with MUX.com video encoding/hosting service.
https://mux.com
MIT License
53 stars 55 forks source link

Unable to use signed URLs #360

Open samuellembke opened 7 months ago

samuellembke commented 7 months ago

Describe the bug When enabling the "Enable Signed Urls" checkbox, it will say "401 Unauthorized" after clicking save. When looking into the 401 request in the network view it gives a request to https://xxxx.api.sanity.io/vxxxx/addons/mux/signing-keys/production?tag=sanity.studio.

This request will get the following response:

{
    "statusCode": 401,
    "error": "Unauthorized",
    "message": "api.mux.com responded with 401 (Unauthorized request)"
}

Normal video uploads work, just the signed urls feature doesn't, therefor it is not an issue with the api credentials, but probably with the implementation of the creation of the JWT token for signing urls.

A clear and concise description of what the bug is. 401 Unauthorized error when trying to enable Signed Urls feature.

To Reproduce Steps to reproduce the behavior:

Install plugin to sanity project. Set API Credentials Upload video Fine Configure API Credentials and check the "Enable Signed URLs" checkbox 401 Unauthorized.

Expected behavior For the signed urls feature to work

Screenshots image

Which versions of Sanity are you using? @sanity/cli (global) 3.27.1 (latest: 3.38.0) @sanity/image-url 1.0.2 (up to date) @sanity/overlays 2.3.36 (latest: 2.3.38) @sanity/preview-kit-compat 1.4.16 (latest: 1.4.17) @sanity/preview-url-secret 1.6.8 (latest: 1.6.9) @sanity/react-loader 1.9.10 (latest: 1.9.12) @sanity/types 3.38.0 (up to date) @sanity/vision 3.38.0 (up to date) sanity 3.38.0 (up to date)

What operating system are you using? Linux

Which versions of Node.js / npm are you running?

10.2.4 v21.5.0

hdoro commented 6 months ago

Thank you for submitting this issue, @samuellembke 🙏

I wasn't able to reproduce this behavior - can you triple-check if your access token and secret keys are correct? After you've checked them, run the following with the Sanity CLI:

sanity documents delete secrets.mux

This will clear the secrets from the dataset and prompt you to re-configure them. To do so, open a field where the mux.video schema is being used and click on the "plug" icon (if no video selected) or on the ellipsis context menu (if a video is selected).

Let me know if the issue remains after these steps :)

jlengstorf commented 3 months ago

I've hit this error and just tried the steps you laid out, @hdoro. I'm still getting the error.

I'm running the studio locally (localhost:3333) and using the "development" environment on Mux.

deps:

  "dependencies": {
    "@sanity/vision": "^3.48.1",
    "easymde": "^2.18.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "sanity": "^3.48.1",
    "sanity-plugin-cloudinary": "^1.1.3",
    "sanity-plugin-markdown": "^4.1.2",
    "sanity-plugin-mux-input": "^2.3.6",
    "styled-components": "^6.1.8"
  },
  "devDependencies": {
    "@sanity/eslint-config-studio": "^4.0.0",
    "@types/react": "^18.0.25",
    "eslint": "^9.9.0",
    "prettier": "^3.0.2",
    "typescript": "^5.1.6"
  },

is there something I can do to help debug this? the error doesn't provide much help, unfortunately, so I'm not sure where to start looking

thanks!

devopsbarista commented 2 months ago

I've hit the same error @jlengstorf and @samuellembke described and the issue persisted even after deleting and recreating the secrets.mux document as suggested by @hdoro.

When looking through the Mux's API docs, I noticed however that Signing Keys have been moved from Video API to System API, hence the operation requires different permissions.

And sure enough, after generating a new access token on Mux with write system permissions in addition to read and write video and read data, everything seems to be working as expected (both upload and preview in Sanity Studio with signed URLs).

Screenshot 2024-09-20 at 4 46 52 AM

One issue that remains though and mentioned in #367 is that signed URL uploads produce assets with both signed and public playback IDs.