Routing changes
Hi! As @NerdyProjects might still remember, I am working to bring all the custom paths/routes (I'm talking about these: https://gitlab.com/foodsharing-dev/dragonfruit-ansible/-/blob/master/roles/foodsharing/templates/nginx-foodsharing.conf#L77) into the foodsharing repository.
Some reasons:
- The way it is right now is a massive roadblock in the way of modernizing routing. Right now, if anything about those custom URLs is changed, or new ones are to be added, we have to take extra special attention to:
- Change foodsharing-dev/images accordingly so dev and CI still work
- Change foodsharing-dev/dragonfruit-ansible to
- not break beta on merge (
try the paths added in this commit on beta for an example: foodsharing@38d7c0be - https://beta.foodsharing.de/freundeskreisfixed by now) - and also not break production on release, most importantly!
- These two goals seem like they are actually rather impossible right now because beta and production are supposed to have the same environment configured? Having to pay attention to any needed config changes seems like a big burden on release day anyway, so doing routing in the application would work much better with how the application is deployed.
- not break beta on merge (
This is because currently, any path that is not handled in that configuration, and that also does not correspond to an actual, existing file, will get 403'd at the webserver level, with a nondescript, static error page.
-
Currently, there's a really ugly hack involving specifics of how fastcgi variables are set to work around our current, equally ugly application level routing (page=x&sub=y). Because porting that to Symfony routing requires using
/virtual/paths/
, duplicating those routes in nginx would get out of hand, and will inevitably also lead to bugs due to writing routes in two different configuration languages with different behavior. -
It would allow us to have error pages that are rendered like any other part of the website, so they actually look like they belong!
Some information on what I've worked out (updated to reflect the current state of things):
-
The foodsharing backend is 100% running through Symfony now (only exception is a very old php file for an iCal API, but a REST based replacement is being worked on: foodsharing!1719 (merged))
-
We can't get rid of the special page routing config immediately. All parts of the application included there need some extra care at the application level to work without those rewrites.
-
A reference nginx config for Symfony applications can be found here: https://symfony.com/doc/current/setup/web_server_configuration.html#nginx.
- The big
location ~ ^/index\.php(/|$)
directive is not actually too different from what we have in production. We just have more .php "entry points" right now. -
xhr.php
andxhrapp.php
are finicky special cases, because they are almost the same asindex.php
, but contain a little request URI workaround - Symfony routing is not designed to take the entry point into account (it excludes the filename from the path before matching it against a route, so xhr.php would normally also match the '/' route)
- The big
-
The dev/CI webserver config is actually more different from beta/prod than I hoped. This will be an opportunity to get them closer together again.
What should be done
-
After the next ("Dragonfruit", December 2020) release, merge and deploy !4 (merged) to fix those routes for the time being. They are currently broken on beta. If you want (and can), you're free to merge it for beta too, however it's not that important. -
There is a "free" simplification available right now: !8 (merged) -
We should look into merging index.php, xhr.php and xhrapp.php into one general entry point. - Any requests for those two files should be handled exactly like a request to index.php, while preserving the proper filename in the request path, so Symfony can pick the right entry point based on that.
- This has to work regardless of whether xhr.php/xhrapp.php is present (due to the difference between beta and production until a release). I gave this a shot, but I'm not good enough with configuring nginx, so I did not find a solution for this :(
- Alternatively, we could also go for the "kurz und schmerzlos" Lösung of deleting the files in git, making a production hotfix and deploying it at the same time as the necessary config changes.
- When this is done, remove the temporary fix added in foodsharing!1888 (merged)
-
Move all static (and publically accessible) files currently in the project root into a new public
directory. Move index.php there too (and adjust the paths in it). Then, set that directory as the new document root in the webserver config and remove the explicit whitelisting of static files (and the default 403). This will:- reduce friction with adding new static files (example: !5 (merged)) by giving developers control over what's accessible and what's not. Also means less work for admins ;)
- clean up the general project directory :)
-
In the webserver config, allow for requests for any path to get through to the application. This will let developers create and change routes in the application repository, so no need to coordinate with admins anymore for this. - If there is a static rewrite in the webserver config, that should take precedence (to not break code that relies on those) - I believe this is already accomodated by nginx's default behavior (more specific location directive wins), but better to verify this.
-
Finally, over the next few releases, the parts of the website that rely on static rewrites should get rewritten to use application level routing. - There is one example of how this will interact with the existing static page routes: foodsharing@84b349ba
As you can see here in the main foodsharing repository, these routes already had to be accomodated to get through Symfony routing, and it is actually possible to change their behavior in the application (
curl -v https://beta.foodsharing.de/unterstuetzung
will show it now forwards tohttps://spenden.foodsharing.de
, which was changed in the aforementioned commit) - This means that the special webserver rewrites can be removed whenever after they have been "taken over" by the application code (and after any request for any path can go into Symfony without special configuration!).
/unterstuetzung
would be the first candidate after the upcoming release.
- There is one example of how this will interact with the existing static page routes: foodsharing@84b349ba
As you can see here in the main foodsharing repository, these routes already had to be accomodated to get through Symfony routing, and it is actually possible to change their behavior in the application (
If you made it this far: thanks for reading my high effort wall of text through until the end. If you have any questions, feedback or opinions, feel free to comment - I am excited to push this forward.