Hey Everyone,
I have thrown together a quick blog post if you are having difficulty in getting CORS working with your Slim project.
http://glenneggleton.com/page/implementing-basic-cors-in-slim
Let me know if you want to see anything else.
Cheers,
Glenn
With Slim 3 I do not believe the CORS solution based on middleware works. I have tried the same solution but …
the middleware stack is not completely processed when the controller or an “inner” middleware handler throws an exception or a Php 7 error
Also if you read the App::_invoke method code you will see that the middleware stack is not executed at all if the notFoundHandler is called. At least thats how I read the code.
To get the simple CORS solution you propose to work I chose to extend Slim\App with my own Application class and override the finalize method so that I could get hold of the response after all processing but just before it was transmitted back to the client.
Finally the middleware CORS approach would be acceptable IF you don’t care about getting understandable responses whenever and and exception or error is thrown or a NOT-FOUND response should be returned.
the middleware stack is not completely processed when the controller or an “inner” middleware handler throws an exception or a Php 7 error
Correct. The execution is halted. If your inner middleware fails then it’s a moot point to return a valid CORS resource as your application itself has failed. You could fix this by modifying Slim’s error handler to inject the CORS header.
Also if you read the App::_invoke method code you will see that the middleware stack is not executed at all if the notFoundHandler is called. At least thats how I read the code
Correct. However again a 404 will need to be handled as a special case. If it’s a wildcard route 404 then that will execute just fine.
I personally don’t make a habit of dealing with these edge cases; as I have QA in place to ensure that neither case above happens in production. they are also quite intensive in skill level which really isn’t appropriate for the majority of our users as solving either issues requires replacement of core Slim Objects.
Might I suggest that the Slim cookbook should at least inform unwary
users of Slim (that is people trying to build apps with Slim) that
middleware will not CORS-enable any response resulting from an exception
or error handler.
Seems a bit slip-shod to view error responses as unimportant “edge cases”.
Personally I like to get as much info as possible back from an API
particularly when something goes wrong.
I am still trying to decide whether it is worth my while to PULL Slim 3
and “fix” the middleware processing or just stick with my current solution.
But in any case thanks for the reply.
Rob
Slim 3 and “fix” the middleware processing
Slim 3 is more or less in maintenance mode as we prepare for version 4.
Version 4 is actively in development which includes many optimizations to Error Handling and Middleware Execution.
Seems a bit slip-shod to view error responses as unimportant “edge cases”.
With proper unit/integration/acceptance testing these outcomes become incredibly small. For example the production environment for a rather popular app (50k requests/hr) receives <0.01% Error Rate. The Errors are caused by either: Bad Actors attempting to probe the system, or Robot/Scrapers misbehaving. Both cases I do not care and/or wish to encourage. This application runs through a fairly non-trivial stack; and we don’t log anything in our Application Layer; Simply sniff response codes the Application produces.
This is of course the solution that I use in my day job; This isn’t the only solution; There are an infinite number of ways to do things.
However for 99.9% of our Users; I would say that the cookbook article is a good reference on how to quickly implement CORS which is all it was written for but we always appreciate other viewpoints and would welcome a PR to update that page. The website documentation is generated from our Slim-Website repository on GitHub; Feel free to create a PR against the CORS cookbook page with any additional information that you think would be valuable.
I only just realized I am being really dumb - the solution to my issue
is simply to surround the call to “next()” with a try catch block and
then handle exceptions and throwables exactly like in Slim\App.
The easy way to do this is to still have a custom App class that extends
Slim\App and use this to get access to the protected methods
handleException and handlePhpError.
So thank for the exchange – it caused me to think about the problem
more carefully.
Rob