Revalidate API token

[tayteboss]

I have to revalidate my API token after I have entered it on the initial start up. I have been trying to show the document in the Sanity Studio as it's described here in the readme

The token is stored in the dataset as a document of the type mux.apiKey with the id secrets.mux. Having the ID be non-root ensures that only editors are able to see it.

I have also tried deleting the studio and setting it up fresh however the keys seem to be stored in cached somewhere and I cannot get that start up screen again. Any information here would be great.

[Lehmons]

Hey, I have the same issue, was there a solution for this. Seems to be cached somewhere, uninstalling the plugin and reinstalling doesn't fix

[Lehmons]

It seems to be cached in the dataset somehow, creating a new one resolved the issue

[HumidBrains]

This plugin seems half baked. There is no info in the UI explaining the signed url opinion and if checked, you cannot revoke your choice. Then you'll have to try to remove all related code everywhere to try to reset, but then you'll get invalid credentials error. Creating a new dataset is not an option for me so for now, no MUX it is.

[Lehmons]

I agree and I am sorry to read this, I do get your frustrations. I was rather lucky for this to happen to me on a small site.

I did the usual, deleted npm, and removed package-lock.j.son.
I then removed this plugin from sanity.config....then reinstalled it all.

To my dismay it is cached in the data set. So I created a new one.

Solution:

• Create a new data set but keep project.
• Renaimed it "production-2".
• Replaced "production" with"production-2" in sanity.config, next.config and sanity.cli.js

It allowed me to reset.

Draw back is you need to then populate the new data set.

[HumidBrains]

As I found out here, the trick is to run this CLI command: sanity documents delete secrets.mux
It deletes the stored mux data in the dataset and you'll be able to reconfigure the API.

[hdoro]

Thank you both @Lehmons and @HumidBrains for the feedback and sorry for the wait and frustrating experience.

We're still considering ways of making this flow more robust, but we've made the following improvements:

• Note on the signing key behavior in the documentation (at the time of writing, it'll come in an upcoming release)
• Ability to configure the plugin's credentials at any time from the uploader/input
  • This allows you to swap the signing key and have the plugin re-generate the private key, which would fix the reported issues

And to clarify, the cached key is private. The _id: 'secrets.mux' document is private via Sanity's ID paths, so you're safe :)

---

I'm closing this issue, feel free to comment and tag me if there's something else I'm missing - thank you again 🙏