3rd-party Plugins
Feature Request
Add the ability to extend Yaak with plugins.
Easy things to support out of the box:
Themes
Request/Response hooks
Importers
Things to come later
Authentication handlers
UI menu items
etc
Add the ability to extend Yaak with plugins.
Easy things to support out of the box:
Themes
Request/Response hooks
Importers
Things to come later
Authentication handlers
UI menu items
etc
Sign in to leave a comment.
The importers are already implemented as plugins, using the Boa JS runtime (Rust)
Highly agree, but installing and removing extensions should be a breeze and fun thing to try out, just like in vscode. Importing files etc is quite annoying.
Ahmed Ifhaam Can you elaborate on what's annoying about importing files? Are you referring to Yaak's data import/export feature?
Gregory Schier No no I was thinking of a "bad" example of installing plugins, in some lightweight apps, you have to import the plugin via a file. I just meant that, that is annoying. Since the spirit of Yaak is to be simple (from what I read at least), making extensions easily accessible, just like in vscode (just a button you can click on the main page, and search quickly, easily (un)install), will do 2 things in my opinion. First, it will encourage users to try out different extensions, and will be a great survey to see what features users want, and later on, the top basic extensions could be built into the app. Secondly, making extensions easily accessible will motivate other people to develop their own plugin/extension.
kindly please take these suggestions under careful consideration, I love the idea & simplicity of Yaak, and would hate to see it drown in features and getting bloated too.
Ahmed Ifhaam My 2 cents here: I think we are jumping ahead; for now, the extensions framework needs to be tested thoroughly (in terms of security, stability and interaction with different APIs which are probably not yet created or finalized); having a full ecosystem where users just comfortably select an extension and also are able to rate it requires a lot of work, including to prepare the secure infrastructure to host it - which is definitely not an easy task (or cheap).
I guess Gregory needs a little time to figure out how to best approach the whole issue.
SoftExpert yes, it's definitely going to be a gradual process but I hope to have something basic out in the next couple months, as it's the next big thing I'm working on.
Gregory Schier
May I suggest to expose as much internals as possible towards the extensions API ?
It would be a powerful feature to have access to the authentication flows (pre / post and "instead of"), to the response (pre / post and also "instead of"), to the "cookies jar" , etc.
Also, allowing to audit / produce data for various steps of the workflow would enable scripting complex testing scenarios …
Kind of related to what SoftExpert said (but I do not see you maintaining an extension store if you already don't want to maintain an open-source project, not a criticism just to be clear !)
May I suggest some kind of permissions system ?
The logic behind your decision of no-open source and plugins instead, sounds pretty convincing to me, but to be really efficient it means the plugins will need to have a much wider access.
I think this raises the risks of supply chain attacks and so if a plugin is going for example to have access to response payloads or environment values, it should be explicitly accepted by the user when they install it
Mickael V Unsurprisingly, I fully agree!
I believe the supply chain attacks could be somehow mitigated by including, since the beginning, a signing mechanism (thus identifying the author and guaranteeing that the code was not tampered with); it will not eliminate 100% of the risks (which approach will, though ?) but it will help by introducing and maintaining the notion of trusted source, ultimately resulting in a security conscious and, hopefully, responsible community.
SoftExpert indeed I was going to mention a signing system too but I was afraid to write too much. I do think the most important though is permissions, like browsers and phones do it
It’s now technically possible to create and install a plugin into Yaak. However, the APIs are not yet that powerful.
Going to mark this as complete for now, and keep working additional APIs, docs, and remote installation https://yaak.app/blog/2024.9.0
There is also now the beginning of some documentation, here: https://feedback.yaak.app/en/help/articles/6911763-quick-start
Congratulations 🎉
You talked about Auth handler and since there is already 3 auth feedbacks requests (JWT, etc). Do you have plan to enhance existing plugin system to be able to add new auth?
Yes, and work on this has already been started. I’m just refining how the plugin API should look and behave