-
Notifications
You must be signed in to change notification settings - Fork 2k
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
CTFd Plugins conflict too much #2511
Comments
Related, possibly, is how to deploy them consistently while tracking upstream. Here is our approach for that: https://gitlab.com/jointcyberrange.nl/ctfd-docker-with-plugins/-/blob/main/Dockerfile?ref_type=heads |
I did something similar, loading plugins from GitHub |
I am happy to hear your ideas but try to keep in mind that the plugins are this way for a reason. Pretty much everyone has their own ideas and visions of what they want to achieve on top of CTFd and by offering a high level of flexibility, generally most people's ideas have been possible. I am a consumer of the plugin system myself so I know it's not perfect but in many situations it has been good to me. |
I don't disagree with the ability to hotpatch anything, it's a powerful feature that python lets us use. The issues I see are mostly related to the ability to combine plug-ins, as two plug-ins that replace the same piece of code can have different interactions depending on load order, some may not load at all, partially load, or crash ctfd. Hot patching also has the problem of relying on implementation details, which makes most plug-ins version dependent. My vision with this issue is to expose some explicit hooks to plug-ins, defining a strict API for it, so that the surface area of what has to be hotpatched is minimized, and therefore the risk of conflict is minimized. |
I attempted implementing plugin dependencies (1. dependencies between plugins, 2. managing plugin dependencies with pip by packaging plugins into python packages) earlier but I ended up in a solution I too am not satisfied with to add to your list, plugins should also have the ability to provide their own translations |
I'm personally not in favor with this (#2509) change since the plugin mechanism allows registering admin pages and many could be achieved through extending templates https://github.com/frankli0324/ctfd-whale/blob/master/templates/whale_base.html I think having a dedicated admin page for configuring plugins not only provides more flexibility and also less chance to be affected by CTFd changes. |
We can move the plug-in configuration section into a dedicated page if need
be.
…On Sat, Apr 13, 2024 at 9:30 AM Frank ***@***.***> wrote:
I'm personally not in favor with this (#2509
<#2509>) change since the plugin
mechanism allows registering admin pages *and* many could be achieved
through extending templates
https://github.com/frankli0324/ctfd-whale/blob/master/templates/whale_base.html
https://github.com/frankli0324/ctfd-whale/blob/master/__init__.py#L41
I think having a dedicated admin page for configuring plugins not only
provides more flexibility and also less chance to be affected by CTFd
changes.
—
Reply to this email directly, view it on GitHub
<#2511 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABITPMPQLVREVFACC4HWBDY5EXOLAVCNFSM6AAAAABFMNHRTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJTGY2DOMRTHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This is exactly against the idea I'm having for plugins, they're currently aliens that modify the CTFd code via hot patching, and they either have to live outside of the rest of CTFd, or they have to modify something and hope nothing else modifies them. Why do the settings exist for each page in a single place, but plugins would have to register their own page for it? I don't see how this lowers flexibility, or even risk being affected by changes, if for some reason they change in the future, then yeah, it can just be refactored out to their own page.
I think dependencies are a good idea, however I don't believe they should exist within the context of the absolute horror that is pip, maybe as a later option, maybe as individual plugins, but CTFd shouldn't depend on it. I drafted down quick notes for a dependency system a while ago which should be fairly quick to implement and easy to use, without having to use external file definitions or draft up an entire dependency resolution system:
Good idea! |
well, 1 and 2 are not dependent on each other in my previous impl, the pip is originally involved for unit test coverage, the idea is that we could achieve both mandatory and optional dependencies with a exception type, plugin |
CTFd's plugin system bases itself on python features, notably, the fact that functions can be modified, wrapped, and replaced entirely at any time.
While this is a good thing for a total conversion, this causes issues when trying to operate multiple plugins, or to keep plugins up to date, as this means that plugins MUST depend on internal implementation details of CTFd.
Some plugins, like
challenge
, are even depended upon by internal code, via theCHALLENGE_CLASSES
global.I'm opening this issue as more of a tracking issue than anything, as I aim to make the CTFd plugin architecture better, with the objectives of:
I'd gladly take suggestions for things to change, but currently, here's what I've thought of:
Pull requests:
If you have more ideas, lmk
The text was updated successfully, but these errors were encountered: