[#29303] - Fix API application routing
- Fixed in Code Base
- 31 May 2020
- Medium
- Build: 4.0-dev
- # 29303
- Diff
- nikosdion:fix/api-routing
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
I was asked by @wilsonge to address the routing issues of the API application using SEF URLs. This PR addresses those issues.
Summary of Changes
- Modified
htaccess.txtto rewrite the API application SEF URLs (e.g./api/v1/content/articles) onto theapi/index.phpinstead ofindex.php - Modified
web.config.txtto rewrite the API application SEF URLs (e.g./api/v1/content/articles) onto theapi/index.phpinstead ofindex.php - Addressed a bug in
ApiRouterwhich prevented semi-SEF URLs (e.g./api/index.php/v1/content/articles) from working
Testing Instructions
Common Preparation
Create an API token by editing your user profile and saving it. Go back into it, click the Joomla API Token tab and copy your token. Further below it's noted as YOUR_TOKEN. Please remember that you must use a Super User token for the API to work!
Moreover, wherever you see https://www.example.com you should put your site's URL.
Apache
Semi-SEF URL
Run curl -H "Authorization: Bearer YOUR_TOKEN" -H "Accept: application/vnd.api+json" "https://www.example.com/api/index.php/v1/content/article"
Full-SEF URL
Copy htaccess.txt into .htaccess first.
Run curl -H "Authorization: Bearer YOUR_TOKEN" -H "Accept: application/vnd.api+json" "https://www.example.com/api/v1/content/article"
IIS
Semi-SEF URL
Run curl -H "Authorization: Bearer YOUR_TOKEN" -H "Accept: application/vnd.api+json" "https://www.example.com/api/index.php/v1/content/article"
Full-SEF URL
Copy web.config.txt into web.config first.
Run curl -H "Authorization: Bearer YOUR_TOKEN" -H "Accept: application/vnd.api+json" "https://www.example.com/api/v1/content/article"
Expected result
You get an HTTP 200 OK response with a JSON document listing your articles.
Actual result
Before the patch the semi-SEF URL would throw errors if URL Rewriting was disabled in Global Configuration.
Moreover, before the path, the full-SEF URL wouldn't work. Instead, the URL was routed to the front-end application which responded with a 404.
Documentation Changes Required
None. It actually helps Joomla work the intended and documented way :)
Post scriptum
I had promised @wilsonge I'd also come up with a solution with NginX and type it as a comment in the PR but I forgot about it
## Enable SEF URLs
# Joomla API application
location /api/ {
try_files $uri $uri/ /api/index.php?$args;
}
# Joomla public frontend application
location / {
try_files $uri $uri/ /index.php?$args;
}
## -- EndOf course if you are in a subdirectory you need to adjust your NginX configuration. For example, if your site is under /joomla:
## Enable SEF URLs
# Joomla API application
location /joomla/api/ {
try_files $uri $uri/ /joomla/api/index.php?$args;
}
# Joomla public frontend application
location /joomla/ {
try_files $uri $uri/ /joomla/index.php?$args;
}
## -- EndVotes
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
Thanks for your fixes. One (general) question: is there a plan how the upgrade path looks for existing .htaccess files from the user?
@bembelimen Joomla has never provided a method to generate or maintain the .htaccess files. It's up to the user to decide how to best implement such a file on their site and/or how they want to customize it. I think this is the correct approach as long as we add a post-installation message about the .htaccess changes like we've done before.
Thankyou very much for this. Looks good on review. I'll test this later on today on a site (can't test this one locally because my apache setup really doesn't play nicely with the Joomla htaccess)
I have tested this item
I have tested this successfully but I have found a scenario not addressed here:
Tested in Apache server.
- Before applying the patch:
a. Without .htaccess in place (Semi-SEF urls): Forbidden. The authorization header does not go through (in token plugin the header is empty).
- After applying the patch:
a. Without .htaccess in place (Semi-SEF urls): Forbidden. (Same as before)
b. With .htaccess in place:
1. mod_rewrite off (Semi-SEF urls): I got the list of articles
2. mod_rewrite on (Full-SEF urls): With or without index.php in the url I successfully get the list of articles.
So this patch addresseses correctly the intended bug, but I found a different scenario in which the authorization header is not passed to the auth plugin if .htaccess is not in place.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29303.
@carcam This is neither a new nor an unknown issue. It's not even an issue with Joomla. It's an issue with Apache.
By default, Apache does not pass the HTTP Authorization header to PHP FastCGI – it does for mod_php. If you're using FastCGI you need to add a .htaccess rule for that to happen. This is why all of Joomla's htaccess.txt files had this magic line:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]This line says "for every request you receive do not perform a redirection, set the HTTP_AUTHORIZATION environment variable to the contents of the HTTP Authorization header and continue processing the rest of the rules". Unfortunately the way it was placed in the htaccess.txt made it inscrutable and misled many a site integrator. As you can see, I've added a more descriptive header for that line in my PR so site owners know not to screw with it
In any case, I knew that would be an issue which is why the Joomla API Token Authentication which I contributed a few months ago already had an "alternate" authorization mode. Instead of the Authorization header please send the HTTP header X-Joomla-Token: YOUR_TOKEN which means that your cURL command line becomes:
curl -H "X-Joomla-Token: YOUR_TOKEN" -H "Accept: application/vnd.api+json" "https://www.example.com/api/index.php/v1/content/article"and works with or without the .htaccess. As you can verify this problem does not exist with NginX or IIS even though they both use PHP FastCGI nowadays (tested on Windows 10 for all three servers and again on Ubuntu 20.04 for Apache and NginX).
So as far as I am concerned this is a wontfix since it's on the web server side (we can't make it go away by default) but we do offer two mitigations: a. the proposed .htaccess code and b. the X-Joomla-Token HTTP header to pass the token without using the problematic header.
| Labels |
Added:
?
|
||
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-05-31 19:22:33 |
| Closed_By | ⇒ | wilsonge |
Thank you very much @nikosdion
Thanks for the detailed explanation @nikosdion
I have tested this item✅ successfully on 03b753a
Tested PR with 4.0.0-beta2-dev successfully on Wampserver 3.2.1, PHP 7.4.5 on Nightly Build of 31 May.
Will also test on Linux and report back if any issues.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29303.