CTFd Plugins conflict too much about ctfd HOT 9 OPEN

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.

from ctfd.

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
comments welcome.

from ctfd.

I did something similar, loading plugins from GitHub
https://github.com/pl4nty/containers/blob/main/ctfd%2FDockerfile

from ctfd.

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.

from ctfd.

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
#2225
just for your reference

to add to your list, plugins should also have the ability to provide their own translations

from ctfd.

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
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.

from ctfd.

from ctfd.

I'm personally not in favor with this (#2509)...

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?
That's just another place where inconsistency existed, and that change brings them closer to being native citizens of CTFd.

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 attempted implementing plugin dependencies...

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:

• Each plugin can depend on another plugin by calling required_dependency("plugin_name") (can also have optional dependencies with optional_dependency("plugin_name"))
  • This function returns True if the plugin loads, False if it fails (only if optional=True, otherwise it exits)
• When this function is called, the current plugin is marked as "building dependencies"
• The next plugin is then loaded, which can, in turn, depend on other plugins
• If this plugin is attempted to be loaded while it's building dependencies, we have a dependency loop, FATAL error, exit
• Once the plugin's call to load() is finished, unmark it as "building dependencies"
• If the plugin is depended upon after it's been initialized, skip initialization and return OK

to add to your list, plugins should also have the ability to provide their own translations

Good idea!

from ctfd.

I don't believe they should exist within

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 load could decide wether a plugin is required or optional and choose whether to throw that exception

from ctfd.