Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] Tauri 2.0: Permissions/Manifest for local plugins? #8962

Closed
martpie opened this issue Feb 23, 2024 · 2 comments
Closed

[bug] Tauri 2.0: Permissions/Manifest for local plugins? #8962

martpie opened this issue Feb 23, 2024 · 2 comments
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@martpie
Copy link

martpie commented Feb 23, 2024

Describe the bug

I am not 100% sure this is a bug, this might just be a Q&A.

I am trying to compartmentalize some parts of my codebase responsible of specific features in plugins. For example, I am trying to group all features related to blocking screen sleep in a plugin, that can be invocated from the front-end.

Example:

// src/integrations/sleepblocker.rs

use log::info;
use tauri::plugin::{Builder, TauriPlugin};
use tauri::{Runtime};

#[tauri::command]
pub fn enable() -> Result<(), String> {
    // TODO
    info!("ENABLE!!!!");
    Ok(())
}

#[tauri::command]
pub fn disable() -> Result<(), String> {
    // TODO
    info!("DISABLED!!!!");
    Ok(())
}

/**
 * Plugin in charge of preventing the app from going to sleep
 */
pub fn init<R: Runtime>() -> TauriPlugin<R> {
    Builder::<R>::new("sleepblocker")
        .invoke_handler(tauri::generate_handler![enable, disable])
        .setup(|_app, _api| {
            // TODO
            Ok(())
        })
        .build()
}
// main.rs
 tauri::Builder::default()
        // ...
        .plugin(integrations::sleepblocker::init())
        // ...

And from the UI, based on user interaction on the setting view:

await invoke("plugin:sleepblocker|enable");

Doing so gives me the following error (browser console):

Unhandled Promise Rejection: "sleepblocker.enable not allowed. Plugin did not define its manifest"

Do local plugins really need a manifest? Do I need to move it out of src/ and to its own lib? I do not intend to publish my plugin, it's really just for me to organize my code.

Or is there a way to define the permissions/manifest locally? Or can I just whitelist all permissions from local plugins?

Reproduction

cf. code above

Expected behavior

No response

Full tauri info output

$ tauri info

[✔] Environment
    - OS: Mac OS 14.3.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 18.17.0
    - pnpm: 8.15.3
    - yarn: 1.22.19
    - npm: 9.6.7
    - bun: 1.0.26

[-] Packages
    - tauri [RUST]: 2.0.0-beta.5
    - tauri-build [RUST]: 2.0.0-beta.4
    - wry [RUST]: 0.37.0
    - tao [RUST]: 0.26.0
    - @tauri-apps/api [NPM]: 2.0.0-beta.3
    - @tauri-apps/cli [NPM]: 2.0.0-beta.3

[-] App
    - build-type: bundle
    - CSP: default-src 'none'; img-src 'self' data:; media-src 'self' asset: https://asset.localhost http://asset.localhost; child-src 'self'; object-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; connect-src ipc: http://ipc.localhost 'self' https://api.github.com; font-src 'self' data:
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite


### Stack trace

_No response_

### Additional context

_No response_
@FabianLars
Copy link
Member

Do local plugins really need a manifest?

Unfortunetely yes. Support for inline plugins was added here: #8781. While there are no docs yet, hopefully the PR helps you to figure it out (it includes an update to our main example app).

I'll close this issue but feel free to keep discussing it. If you're facing any bugs we can reopen it :)

@FabianLars FabianLars closed this as not planned Won't fix, can't repro, duplicate, stale Feb 24, 2024
@martpie
Copy link
Author

martpie commented Feb 24, 2024

Thank you! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
None yet
Development

No branches or pull requests

2 participants