Hey all! I don't really know what happened but today I started up my dev environment to work on my extension that adds middleware and it just doesn't work anymore. I've isolated the problem to the __invoke method not being called for some reason. Here is the code I'm trying to use: Event Handler: class ConfigureMiddlewareListener { /** * @var Dispatcher $events */ protected $events; protected $logger; protected $prefix = "Bearer "; public function __construct() { $this->logger = new Logger("flarum_jwt_ext"); } /** * @param Dispatcher $events */ function listen(Dispatcher $events) { $this->logger->debug('listening to events'); $this->events = $events; $events->listen(ConfigureMiddleware::class, [$this, 'handler']); } /** * @param ConfigureMiddleware $event */ public function handler(ConfigureMiddleware $event) { $auth = new AuthenticateWithJWT(); $event->pipe($auth); } } if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } AuthenticateWithJWT.php class AuthenticateWithJWT { protected $logger; public function __construct() { $this->logger = new Logger('flarum-ext-jwt'); $this->logger->emergency('constructed'); } public function __invoke(Request $request, Response $response, callable $out = null) { $this->logger->critical('invoked'); return $response->withStatus(500); } } if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } Any ideas? Nothing gets logged as an error. I see 'listening to events' and 'constructed' in the logs but that's it. It seems to only not invoke on API routes, but all responses for some reason come up as blank 200 responses regardless of it being an api request or not.

__invoke not being called when trying to add middlewares

Franz

BitForger Which version are you running on? Are you on a fairly recent dev-master by any chance? If so, we have recently updated the middleware interfaces. That might be the problem.

BitForger

Franz Ahh interesting! I need to check. I have copied versions being maintained internally (this is a client project) that are using dev-master as the branch. I should check and make sure it's not pulling those versions. I should be using the 0.1.0.beta-7 version though.

BitForger

Franz It looks like i'm still pulling v1.3 of stratigility so the layout should be valid.

clarkwinkelmann

I was under the impression $event->pipe() may only receive a callable as a parameter, not an object. I've been using $event->pipe->pipe($middleware) in all my extensions so far.

BitForger

clarkwinkelmann Interesting, that seemed to resolve it. I don't understand why it was working the other way in the first place then. ¯_(ツ)_/¯

BitForger

Sort of a follow up problem, I have the middleware working now (sort of) but now all requests are coming back blank. They (the requests) run through all my code without raising exceptions but for some reason everything that comes back is blank. It seems like this has to do with something in flarum. Completely removing the middleware doesn't remedy the situation.

clarkwinkelmann

BitForger is your code online or can you post it here ?

Without seeing anything I suggest you check you're passing and getting the response through $out() and returning it ?

When you say removing it doesn't fix it, how exactly did you "remove" it ? Does it also happen with the extension disabled ?

It's possible there is an error that is not show in Flarum. Check your webserver logs when working on that kind of thing, they may contain PHP errors that aren't thrown as exceptions.

BitForger

clarkwinkelmann Yeah, here's the gist

I commented out the pipe running the class.

The problem is nothing is showing up in logs so I have no idea what is wrong. I log pretty much every step and it doesn't help me determine anything. Though it does look like I don't make it to my extension endpoint so there has to be something throwing an exception but it's not being handled correctly.

BitForger

After more digging, it seems that the path getting setup for the DispatchRoute class is //api which would is, for some reason, preventing the __invoke method of DispatchRoute from working. I can force the route back to /api but it throws errors. However, when forcing the route to /api, DispatchRoute gets invoked and api endpoints are hit. They still have an empty response however.

BitForger

After many hours of debugging I have resolved the issues. First one, the actor wasn't getting put on the request unlike I had previously believed. Second, trailing slashes in your URL config causes it to parse routes to the API as //api which is problematic.

Franz

BitForger Glad you solved it. Anything we can do to make this sort of thing less problematic to debug? Exceptions (or automatic removal) when having trailing slashes in the base path, for example?

BitForger

Franz Yeah I think either striping trailing slashes on the base or leading slashes on the path would fix it, or just make it documented somewhere how it's supposed to be configured. Also, I think handling the exception thrown and returning a more descriptive error would be immensely more helpful. Right now you just get thrown a generic error and we had to walk through all the way back to the level where we realized that it was because I didn't set the full actor on the request. If the value of the variable was verified first then a proper error could have been sent that would have allowed me to identify much more quickly the problem. I forget where it was exactly, it may have been line 60 of ListTagsController that was setting the value but not verifying it was valid.

I will grant that this stemmed from my code but there is a level of inflexibility in adding custom authentication layers in the way the middlewares are setup. For example, I am now perpetually locked out of the admin panel because the permission is asserted before I get a chance to put the user on the request. Permission checking should be run after middlewares are configured IMHO since they main goal of a middleware (for many cases) is to run some sort of authentication.