Add-ons and 25.02.1 default AnkiWebView api access - workarounds?

Anki Add-ons
1

The Contanki add-on inherits from AnkiWebView, similarly to my add-on.
But because of the new security precautions in 25.02.1, if the webview is not one of the specified allowed enums, it won’t have an authorization token inserted in its headers. Because there’s no kind set, it defaults to AnkiWebViewKind.DEFAULT which isn’t allowed access.
The quick and hacky fix is to piggyback on one of the whitelisted AnkiWebViewKinds when initializing, so something like super().__init__(kind=AnkiWebViewKind.EDITOR). I’ve tested this and both add-ons work again.

I’m a newbie so I’m not sure of the ‘proper’ way to fix this. Do we consume the _APIKEY from aqt.mediasrv and set our own headers? Or is there any other way? Advice appreciated.

I didn’t post this in the main github issues as i didn’t feel like it merited a thread over there. Hope it’s okay to post this here.

3 Likes
2

Thanks for the report! I filed a PR to address this, with major credits to @llama for their previous work.

5 Likes
3

Thanks for the fix! I guess I was wrong in my assessment :frowning: - the api doesn’t matter, just that there was no onBridgeCmd being passed for a DEFAULT kind because of the if check in set_kind thus not giving us access to pycmd in the webview.

3 Likes
4

I made and released a small add-on to download the Contanki patch based on your workaround. This is intended as a temporary workaround until Glutanimate’s Pull Request is incorporated into Anki and released, so it will soon be no longer needed. :inbox_tray:Contanki Patch Downloader for Anki25.02.1 (Fixed by Shigeඞ) https://ankiweb.net/shared/info/704628562

1 Like