Christoph Kappestein | Blog

Exploring solutions to build a secure plugin system for PHP apps

2026-04-12T21:17:00Z

Cloudflare has recently released EmDash which is marketed as secure WordPress alternative. The main selling point is that EmDash is more secure since it does not execute plugins in the main app like WordPress does, in WordPress a plugin can easily access every table so that a single malicious plugin can corrupt your complete website, since in the end a plugin is only PHP code which gets included to the main app. This is indeed a problem and many security issues are introduced due to plugins. In this post I like to discover current solutions and ideas how we could build a secure plugin system.

In general plugin systems are a central part of many projects which allow users to customize or extend specific parts of an app. Especially for open-source projects it is a great way to build larger ecosystems, because of this building a secure plugin system is an important part for many systems. It of course also depends on the size of the project and for small projects it is perfectly fine to simply include PHP files as plugin. Let's start by looking into available solutions:

Scripting language

While PHP itself is already a scripting language there are extensions to execute another scripting language within PHP. One approach which Wikipedia has choosen is the integration of LUA as scripting language for plugins. They have also developed the LuaSandbox PHP extensions to control CPU and memory limits for script execution.

The v8js PHP extension integrates the V8 JavaScript engine. This is a heavy solution since integrating the v8 engine comes with additional complexity, since your users need to install this additional extension which makes setup more complicated.

Recently I have found ScriptLite which executes a subset of ECMAScript but without the need to include V8 since it actually parses and executes the ECMAScript in PHP. This looks promising, but it is a very new project so we need to wait and see how it matures.

WASM

In theory WASM would be the perfect solution, we can compile code from different programming languages into WASM and then run this safely in our app, like it is also executed in the browser. But unfortunately this is currently only in theory since there are many details missing for example there is no easy way to share complex data structures like strings, arrays or objects. The PHP ecosystem has currently also no active maintained extension to run WASM code. So in the future this could be a great way but the ecosystem still needs to evolve.

DSL

Besides integrating an existing scripting language an alternative solution would be to build a custom DSL, which your users can use to customize the app. There are tools like ANTLR which really help to develop such custom DSLs but this is of course also a complex task and this makes only sense if you build a domain specific language and not a general programming language, since in this case you would be better off using an existing scripting language.

Transpiler

A transpiler parses PHP code and removes from the AST all dangerous code so that you (in theory) only execute a safe sub-set of PHP. I have also built such a Transpiler but in the end this is of course also not safe and still a security risk since there will be always security issues where the transpiler does not correctly sanitize the code.

REST API

Instead of running your plugin inside your code with this idea a plugin is a small service which provides a REST API to handle the logic. This is really secure since the plugin runs in a complete separate environment without access to the database or filesystem. This is also used by Shopify and I have recently found WPApps which brings this idea to WordPress. But of course this setup is more complex since you now need to host every plugin.

Conclusion

To reference back to EmDash and WordPress, if PHP would have a stable scripting language the WordPress plugin system would be (maybe) in a better state, since it could be used for safe execution of such plugins. From the projects we can also see that there is a demand. There are probably also many closed-source apps which have this requirement. I think the PHP ecosystem would greatly benefit from a solid and stable scripting language to run untrusted code.

Looking into the future if such a scripting language evolves we may also create a PSR standard for script execution. I.e. we could define a simple interface and different environments could provide different implementations to enable script execution.

interface ScriptEngineInterface {

    /**
     * Executes the provided script code
     */
    public function execute(string $code, Context $context): mixed;

}

This is of course only a rough idea, but it would be a great step forward to build more secure systems.

Matomo setup Auto-Archiving with Docker

2025-09-21T20:32:00Z

Recently I have migrated all analytics of our projects from Google Analytics to Matomo. Matomo is a self-hosted alternative to Google Analytics with better privacy handling. Since all our projects run on Plant we use the official Docker-Image to run Matomo.

For larger websites it is recommended to set up Auto-Archiving, which helps to process our analytics data in the background. The docs explain the setup for a plain installation but to execute the cron in side the docker container you need a different command. Our host server runs on Ubuntu 24.04 and to execute the cron we simply configure the following cron on our host system:

5 * * * * root /usr/bin/docker exec -t [container_name] /usr/bin/bash -c -i "./console core:archive --url=https://[your_url]/" > /tmp/matomo.log

This is basically only s short post to document this for the future and maybe this can also help others.

Fusio 6.0 released

2025-09-06T14:30:00Z

Today we have released the next major version 6.0 of Fusio. Fusio is an open source API management platform which helps to build APIs. In this post I like to talk about the new features of the 6.0 release. For all technical details you can take a look at the release post.

Connection designer

From the beginning Fusio was always a tool with a feature-set between an API gateway (like Kong or Tyk to route traffic to internal services and handle authorization etc.) and a backend (like Firebase or Supabase where a developer can build actual endpoints). The backend part was always a bit behind since you would need to use external tools i.e. like a database management tool or an HTTP client to build a backend. I think with the 6.0 version we have finally completed the backend feature-set so that it is now possible to build complete apps without leaving Fusio. This is possible through the new connection designer panels which we have implemented s.

The connection list contains external service which you want to use in your app, in this example we have a mysql database connection, a remote HTTP starwars API and a local cache dir folder on the filesystem. At each connection there is now a new terminal button right beside the edit button (which we call designer) which you can use for each connection. The button redirects you to the fitting designer for the connection type. In the following I will cover the three new designer types.

Database

The database designer contains an overview of all tables, it is possible to create and modify the schema of each table. It is also possible to view and edit rows on each table. Through this you can design and manage the database schema for your app.

HTTP

The HTTP designer provides a small HTTP client which can be used to invoke external APIs. This can be useful to test an API before actually implementing it in an action.

Filesystem

The Filesystem designer shows all files at the filesystem connection and provides also a way to upload new files.

Currently, we have also some connections like a Message-Queue or MongoDB connection which has no designer, but we plan to implement this in the future. The designer panels help also to close an important feature gap for a potential Fusio cloud service, so that developers can register and build complete apps directly within Fusio.

MCP (Model-Context-Protocol)

With Fusio we don't want to jump directly on the AI hype train, but we have looked at it carefully and found a great way how we can help LLMs to interact with Fusio, which also stays true to the self-hosted spirit so that we don't force our users to use external APIs. The solution is the integration of an MCP server. Through this you can now invoke all operations through an LLM. To integrate the MCP server we support the stdio transport through a simple command:

php bin/fusio mcp

We have also experimental support for the HTTP transport but this is disabled by default, so you need to activate this in the configuration, if enabled you can use the /mcp endpoint. Through this MCP server you can invoke the internal backend operations via an LLM, which you can use to build your API, but the same logic can be also used for the API which you have build with Fusio, thus we have created automatically an MCP server for all our users. This feature is completely new but provides many exciting possibilities how you can use and integrate Fusio with LLMs.

OAuth2 authorization server

A great feature of Fusio are the dedicated apps which you can install through our marketplace. For example the developer app, which helps to build a developer portal or also the backend app which is used to manage your Fusio instance. All those apps are basically javascript apps which work with the Fusio API.

With this release we have implemented a new OAuth2 authorization server which automatically integrates with every app, this means that you automatically get a new OAuth2 login button s.

On click on the "Fusio" login button you get redirected to the internal OAuth2 authorization server.

There a user needs to authenticate and approve the authorization. The user has also the option to deselect specific scopes so that the app can access only specific parts of the API. This also helps our users to build complete new apps and use Fusio as authorization server. Since we also only follow the OAuth2 specification a user can easily later on swap the OAuth2 server with a different provider.

Conclusion

Personally I have the feeling that the 6.0 release marks a really great milestone for the Fusio project, which is now solid open source platform to build APIs. If you need to build an API or you have an API related task feel free to give Fusio a try. For more information you can take a look at our website and if you want support us you can also give us a star on GitHub.

Lessons learned from building a Docker-based server panel

2025-06-28T17:03:00Z

Today I have released a first version of Fusio Plant which is an open source server management tool to easily self-host apps on your server, in this post I like to share some experiences of this process.

While building Plant, we had the goal to keep the host as small as possible, we basically only wanted to install Nginx and Docker and start all projects through a simple docker-compose.yml file. We also wanted to run the Plant app itself as docker container so that it is easy to update the server panel itself. Moving the Plant app into a docker container means also that we can no longer directly execute commands on the host. In general, this is a good thing, but for a server panel we need the option to change i.e. the Nginx configuration or run Docker commands on the host.

Host Docker communication

In the development process, we had developed three versions to enable this Docker to host communication. These ideas are maybe also useful for other scenarios, so I will walk you through each version.

Cron

The first implementation used a simple cronjob which executed a bash script. The bash script walked through each file in an input/ folder, executed each file and wrote the output to an output/ folder. Those input/ and output/ folders are also mounted into the docker container and inside the container we wrote a command into the input/ folder and waited until the result was available at the output/ folder.

The biggest limitation of this solution was speed since cron can execute a script only once every minute. This means in the worst case, a user needs to wait almost a minute for the command to be executed.

inotifywait

To improve the performance we tried to use inotifywait which is basically a tool which you can use to listen for file changes inside a folder. The setup is basically identical to the cron version but instead of cron we use inotifywait to listen for file changes inside the input/ folder and then write the result to the output/ folder. To run this script we have also used supervisord to keep the bash script alive in case of errors.

Initially this has worked and improved the performance greatly, but unfortunately there are some scenarios where inotifywait could not detect file changes in case the Docker app placed multiple files into the input/ folder.

Named pipe

As the last and final solution, we have changed the input folder to a named pipe. We can then mount this pipe into our Docker container and write events directly into this pipe. On the host we can then listen to this pipe and execute events directly on occurrence.

The bash script on the host can now easily listen for changes on the pipe s.

input=/opt/plant/input

while true
do
  while read -r line; do execute_command "$line"; done < $input
  sleep 1
done

To write events to the pipe, we can use basic file functions s.

$input = fopen('/tmp/input', 'w');
fwrite($input, '{"type": "my_command"}');
fclose($input);

After writing the command to the pipe we can directly check the /output file and wait for a response. To veriy that the script was fully executed we check for a specific --EOF-MARKER-- marker at the end of the file and if its available we stop reading the file.

$response = '';
$outputFile = '/tmp/output';
$output = fopen($outputFile, 'r');
$count = 0;
while ($count < 32) {
    $size = filesize($outputFile);
    if ($size > 0) {
        $response.= fread($output, $size);
    }

    if (str_contains($response, '--EOF-MARKER--')) {
        break;
    }

    usleep(100_000);
    clearstatcache();

    $count++;
}

fclose($output);

The clearstatcache call in the snippet above is crucial since PHP automatically caches the responses of the filesize function, so we need to clear the cache on every iteration to get the live file size which often changes on command execution.

Conclusion

As a conclusion, we have looked into three solutions to enable Docker host communication. In our case, the named pipe solution works perfectly since it is fast and lightweight, and we can now easily execute commands on the host system. In case you are interested in a new Docker-based server management tool, check out the Plant GitHub repository.

TypeSchema a JSON specification to describe data models

2025-01-02T23:03:00Z

In this post I like to talk about the TypeSchema specification and the changes of the latest version.

To start, TypeSchema is a JSON specification to describe data models in a language neutral format. Basically it can be seen as an alternative to JSON schema with a focus on code generation (and not validation). It helps you to build type-safe applications by sharing core data models in different environments.

The TypeSchema specification is reversible, this means you can transform a TypeSchema specification into actual code and then use a reflection library to turn this code back into a TypeSchema specification without any data loss s.

Generator           Reflection
|                   |
TypeSchema ---> Generated Code ---> TypeSchema

In this case the TypeSchema on the left is identical to the TypeSchema on the right. To give you a practical example lets take a look at the following TypeSchema specification:

TypeSchema

{
  "definitions": {
    "Student": {
      "type": "struct",
      "properties": {
        "firstName": {
          "type": "string"
        },
        "lastName": {
          "type": "string"
        },
        "age": {
          "type": "integer"
        }
      }
    }
  },
  "root": "Student"
}

Through the code generator we can turn this specification into actual code, in this example we use the Java generator.

Generated Java Code

import com.fasterxml.jackson.annotation.*;

public class Student {
    private String firstName;
    private String lastName;
    private Integer age;

    @JsonSetter("firstName")
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    @JsonGetter("firstName")
    public String getFirstName() {
        return this.firstName;
    }

    @JsonSetter("lastName")
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    @JsonGetter("lastName")
    public String getLastName() {
        return this.lastName;
    }

    @JsonSetter("age")
    public void setAge(Integer age) {
        this.age = age;
    }

    @JsonGetter("age")
    public Integer getAge() {
        return this.age;
    }
}

Now we can use the reflection library to transform this model back into a TypeSchema specification which looks exactly like the schema defined above.

This should give you a rough understanding how TypeSchema works, for more details please take a look at the website or specification.

Changes

With the latest version we have moved away from the JSON Schema compatibility which we had for some years, this means we now use dedicated keywords which are not compatible with JSON Schema so you need to decide whether you want to use TypeSchema or JSON Schema. The following list covers the important changes.

Validation

We have removed all validation keywords from our specification i.e. required or minLength to make clear that TypeSchema helps you only to model your data, it is not intended to validate your data. We also no longer use the dollar sign $ at our keywords since they make it more complicated for code generators to process.

We think that validation must be done in your domain layer, where you also generate fitting error messages. At TypeSchema you only describe which fields are available and our code generator can then generate DTOs for every object structure. These DTOs can then be used at your domain layer to validate the incoming data.

Union

We have removed support of the oneOf keyword. At the code generator we have noticed that for dynamically typed languages it is easy to represent actual unions, statically typed languages like Java or C# have a much harder time to represent such dynamic data types. But they all can represent a tagged union. This is also the concept which is now supported at TypeSchema, instead of guessing the fitting schema a user needs to provide a concrete type identifier which is mapped to a concrete type definition. This is also heavily used at our meta-schema to describe the TypeSchema specification itself.

Type

Because of this union change we now also require a type property on every type. For example previously you could use the $ref keyword now you need to use the "reference" type s.

{
  "type": "reference",
  "target": "My_Type"
}

I'm really happy with the current TypeSchema version and I think we have made many solid designe choices for the future. Basically TypeSchema could evolve into a general JSON format to represent a model in a language neutral format.

Ecosystem

To give you a short outlook into the ecosystem, there are several projects in development which are basically based on TypeSchema. At first there is a new specification called TypeAPI which helps to describe complete REST APIs for code generation, which internally also uses the TypeSchema models. Then there is a platform called TypeHub which helps to manage TypeSchema/TypeAPI specifications and the SDKgen app which provides a great code generator to turn an TypeSchema/TypeAPI specification into client code.

Introducing the DeutschlandAPI project

2024-09-07T23:13:00Z

I like to introduce you to the DeutschlandAPI project. The DeutschlandAPI is basically an open API which combines and aggregates multiple open government APIs of germany into a single consistent and easy to use API. This project is a first step to help developers get open and public information of germany.

While building this API I thought about the general concept of a country API. Basically a standard API which is provided by each country to get all available information of the country. This could enable many great use-cases where an app can dynamically get all up-to-date information about a specific country. In the following I will go through interesting fields which could be useful for such a country API.

Geodata

At first the API should expose all basic information how the land of a country is structured, in germany we can split this up in states, districts and cities but for other countries this may be different. This could also include streets so that apps can always validate correct address data and build up-to-date dropdowns.

Companies

Every developed country has some sort of register where every official company is registered. In germany we have the Bundesanzeiger which basically is such a register, you can see also the annual accounts for each company, but I think it would be enough to have a register which lists the company names, corporate form, business objective, the physical address and a link to the website.

The Bundesanzeiger has unfortunately no public API so it is not included in the DeutschlandAPI, but I would like to add this in the future. Such an endpoint could make it easier to get information about all companies inside a country. Today there are even services available which sell these kind of company information, but I think it would add a great value to have such directories free available.

Warnings

Most countries have also a basic warning system, to warn the citizens in case of fire, extreme whether, biological or nuclear events. In germany we have the MoWaS which basically provides a warning system covering those events. This is also integrated in the DeutschlandAPI project.

Statistics

It would be great to have general statistics about a country like the population, GDP or unemployment rate. In germany we have the Statistisches Bundesamt which collects all kind of statistical information of germany, but there are really many statistics about many topics like the population, education, habitation, economy, trade, finance etc. I am currently trying to figure out which of these information would be really valuable for such a statistic endpoint.

Jobs

Most countries have a job search which is managed by the government. In germany we have the Arbeitsagentur which basically is such a job platform managed by the government. This could help to integrate job searches into different apps depending on the country. There are of course also many private networks available like LinkedIn but it would be great to integrate a general job search provided by the government.

Electricity

A key information of each country is also the power production and consumption. We could add an endpoint where we simply return the current (or maybe also historical) values how much power a country has produced or consumed. This is also a great indicator how developed a country is.

Conclusion

The mentioned fields are first ideas which could be useful for a general country API. Those described endpoints are also read-only, if we think about POST endpoints we could open up also many more interesting use cases like replacing emergency numbers like 110 with a post endpoint where every citizen could send a request. But those endpoints would require a safe authentication of a citizen which is currently not possible. With the DeutschlandAPI project I have tried to build a first country API, if you also like to implement a similar API for your country please take a look at our API documentation.

Building infrastructure software without central authority

2024-08-30T18:40:00Z

To better explain the problem I am thinking about I like to go back in time.

Freshmeat

At the start of my open source journey there was a website called Freshmeat, which was used by developers to announce new releases, you could also browse and find existing projects. This was before GitHub existed and at that time I really liked this site as a central place to get information. Over time the demand decreased and the site closed, there is currently still a replacement active called freshcode.club but it has no longer the traction of the original service.

Awesome lists

I think the modern successor of Freshmeat are so-called "Awesome lists" on GitHub, basically these are simply repositories with markdown files containing links to interesting tools. The reason why these lists overtook software directories like Freshmeat is probably socially, because now every user could add suggestions by opening a pull request. This is really great and has helped to create "awesome" lists but over time this has still some problems:

Since every repository has a central owner which needs to accept and merge pull requests there are many lists where the original author is no longer active so that nobody can modify an existing list. You could of course fork such a list but then you have many duplicated lists and nobody knows the currently active maintained list.
Most lists contain also out-dated content since it is really difficult to keep those lists up-to-date.

Infrastructure software

Software directories like Freshmeat and also Awesome lists have both the problem that they have a central authority which needs to curate each entry. I am currently thinking about a solution for this problem so that we can build software without a central authority. This could allow us to create lists which are always up-to-date and evolve over a long period of time. Because of this I like to call this "infrastructure software" basically a piece of software which can run on a server without moderation or central authority.

You may think, this sounds cool but how could this be possible and how can you prevent spam?

I think we should come back to the basic building blocks of the internet. To protect against spam we need a resource which is limited, for the internet the perfect limitation is a domain. You can only add an entry to our list if you have a custom domain, this automatically limits participation only to users with a custom domain. To verify the ownership of the domain we could add a verification through a DNS TXT record.

As second step if a domain was registered to our list we reverse the data flow, instead of adding an entry directly to a central database the domain needs to provide an endpoint where the information gets returned. For example, we could request on every domain the following path /.well-known/software.json and check the response, on success this endpoint returns all information of our entry on the list.

Through this the owner of the domain can easily update the information of the entry by simply updating the software.json resource on the server. Our list aggregation service can then check all domains periodically for updates. We could also delete or hide an entry in case the resource returns an invalid status code like 404 or 500.

Conclusion

I think this idea is really great and could help to build software directories which could be always up-to-date and run for a really long time. Every user on the internet can add a new entry by submitting a custom domain to the list. There are still some challenges since we need a great JSON format to describe a software entry and there needs to be a great aggregation service which provides an intuitive UI, but those technical challenges are easy solvable.

Currently this is still an early idea and there is no implementation, so please contact me if you like the idea and would participate on such a directory. I am really motivated to move this forward to make the web more decentralized and better.

Reboot my personal blog

2024-08-24T14:57:00Z

With this post I like to reboot my personal blog. In the past I have used for a long time medium.com as blogging platform but there are several reasons why I am no longer happy with the platform. I have thought about choosing one of the thousand alternative platforms for blogging but in the end they all have downsides. Instead of going through all downsides I like to share my thoughts about the advantages of a self-hosted blog, maybe I can convince also some readers to start again with a self-hosted blog.

Data sovereignty

If you host your own blog the content of your blog is under your control. An external blogging platform is a company which needs to make money, they need to somehow use your blogging content to create revenue since they offer the platform mostly for free. This is done by adding some kind of partner program or paywalls. On your own blog you are complete free from those topics and you can get sure that your content is not misused.

Data durability

Your thoughts and ideas which you write are an important part of your legacy. You probably want that this content is also available after your lifetime. Blogging platforms are limited to the lifetime of the company behind the platform which is often not too long, if the company closes your content will also disappear. If you host your own blog you have automatically multiple mechanisms to archive your content. In my case I use a public GitHub repository where all posts are stored. Then your blog is probably also covered by archive.org which creates over time a complete backup of your blog. Through your own domain and content you basically participate in the history of the internet.

Data quality

Most blogging platforms provide some kind of WYSIWYG editor to write your content. Such editors often produce ugly HTML and they are also limited. Especially for development content I find often examples where code examples or code-highlighting are broken. If you want to preserve your content for the long term it is probably better to write the HTML content by your self, this ensures better data quality and makes it better readable.

Decentralization

This is an idealistic point but if you host your own blog you help to decentralize the web. You may know the largest problem of the current web is centralization, this means that there are only some centralized platforms or so called data silos like Twitter, Facebook etc. where all content gets created. In the end those platforms are dependent on your content, if you decide to move this content to your own blog you remove some power from those platforms.

Conclusion

These points have convinced me to start again with my own self-hosted blog. But there are of course also some disadvantages. The largest disadvantage is probably discoverability, on a central platform you get automatically readers from the users on the platform, on your own blog you depend on a search engine to find new readers. In the future it would be cool to have some kind of aggregation service where self-hosted blogs could register to reach a wider audience, to support those self-hosted blogs.

Future

Regarding this blog, in the future I will write content around my open source projects and in general development topics like API management, REST, code generation, specifications and decentralization. I will also go through my old medium.com posts and transfer them to this blog. If you are interested feel free to subscribe to the feed.