Skip to content

[1.x] feat(phpstan): report misaligned extender callback parameters - #5050

Open
DavideIadeluca wants to merge 1 commit into
flarum:1.xfrom
glowingblue:di/static-analysis
Open

[1.x] feat(phpstan): report misaligned extender callback parameters#5050
DavideIadeluca wants to merge 1 commit into
flarum:1.xfrom
glowingblue:di/static-analysis

Conversation

@DavideIadeluca

@DavideIadeluca DavideIadeluca commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Fixes #0000
It's too easy to register an ApiSerializer callback with a misaligned signature. Take the following proof of concept:

use Flarum\Extend;

return [
    (new Extend\ApiSerializer(ForumSerializer::class))
        ->attributes(function (ForumSerializer $serializer, array $attributes): array {
            $attributes['foo'] = 'bar';

            return $attributes
        }),
];

The above code passes static code analysis but it serializes raw model data to API responses which means that it introduces a major security vulnerability.

Changes proposed in this pull request:
Implement a new custom PHPStan rule which checks the signature of select extender callbacks. It reports:

  • Documented parameter names declared at the wrong position
  • A parameter type that core cannot accept
  • When $models are returned

Reviewers should focus on:
The new rule doesn't catch absolutely all possible cases how this can be done wrong, but it provides a great deal of protection against silly unintended mistakes. I thought long if there are genuine cases this rule is undesired, however I didn't find any. Extension Developers can still use the phpstan ignore directive to work around this issue if an implementation somehow genuinely needs to do something which doesn't pass this rule.

For Flarum 2 we should consider if we want to narrow down the runtime logic to fail loudly in such scenarios where applicable. Some mitigations on this were already done if I recall correctly, like using $hidden to hide model data from being serialized to begin with. Let me know what you would like to see for Flarum 2 here.

Screenshot

Necessity

  • Has the problem that is being solved here been clearly explained?
  • If applicable, have various options for solving this problem been considered?
  • For core PRs, does this need to be in core, or could it be in an extension?
  • Are we willing to maintain this for years / potentially forever?

Confirmed

  • Frontend changes: tested on a local Flarum installation.
  • Frontend changes: tests are green (run yarn test in js/).
  • Frontend changes: tests have been added, or are not appropriate here.
  • Backend changes: tests are green (run composer test).
  • Backend changes: tests have been added, or are not appropriate here.
  • Where applicable, changes are suitable for all supported database drivers (MySQL, MariaDB, PostgreSQL, SQLite).
  • Core developer confirmed locally this works as intended.
  • The description above is written by me and describes what this pull request actually does.

Required changes:

  • Related documentation PR: (Remove if irrelevant)

@DavideIadeluca
DavideIadeluca marked this pull request as ready for review September 9, 2026 17:21
@DavideIadeluca
DavideIadeluca requested a review from a team as a code owner September 9, 2026 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants