[#30067] - Success true and status header 200 OK when sending a request to a disabled AJAX plugin
- New
- Medium
- Build: master
- # 30067
Steps to reproduce the issue
Install the following plugin
ping.xml
<?xml version="1.0" encoding="utf-8"?>
<extension version="3.8" type="plugin" group="ajax" method="upgrade">
<name>plg_ajax_ping</name>
<author>teflonmann</author>
<creationDate>10.07.2020</creationDate>
<version>1.0.0</version>
<description>AJAX Ping Test</description>
<files>
<filename plugin="ping">ping.php</filename>
</files>
<config />
</extension>
ping.php
<?php
defined('_JEXEC') or die();
class PlgAjaxPing extends JPlugin
{
public function onAjaxPing()
{
return 'pong';
}
}
?>
and call http://example-domain.com/index.php?option=com_ajax&format=json&plugin=ping
Same result when you switch the format parameter to raw or debug as mentioned here https://docs.joomla.org/Using_Joomla_Ajax_Interface.
Expected result
When the plugin is disabled, the request should in my opinion give back a status 400 header and "success":false, so that a check at the sender's site is informed, that the request did not work and it is not just an empty result.
Actual result
The system reply looks currently like this:
header Status: 200 OK
{"success":true,"message":null,"messages":null,"data":[]}
System information (as much as possible)
Joomla! 3.9.19 Stable
PHP 7.4.7
Additional comments
joomla-cms-bot
- 
com_ajax doesn't target a single plugin. It just triggers an event. Multiple plugins could act on it.
I don't know if a single Ajax request should return a "success":false in this case. I don't know what the standard is. Something for experts.
But I think it would be a B\C break in Joomla 3.
To me it would make sense to use this as a callback instead of triggering a plugin event. Other plugins returning garbage data is unexpected to me. But I guess there's a use case for both.
IMHO not a bug
While I cannot think of many scenarios in which one introduce a "public" interface and then either accidently or intentionally deactivates that endpoint and / or uses it without proper checking, I do agree that, if the module / plugin in question is "unpublished / unavailable", both the status in the JSON response and the HTTP status code should reflect that the endpoint is unavailable (success = false, message/s: Endpoint unavailable / not found), [...]).
As for the HTTP status code, I would expect a 404 to be returned instead of the proposed 400. The difference here is, that the request in itself might be perfectly valid, but the endpoint simply "not found".
com_ajaxdoesn't target a single plugin. It just triggers an event. Multiple plugins could act on it.
Correct me if I'm wrong on this; surely there might be a way to hook into a generic ajax request with another plugin, but if the endpoint, be it a module or a plugin like in the ops example, was specifically requested, there should be no confusion as to what method is called in the respective extension, right?
Apart from that, and this could be a subject for another PR - if you call com_ajax with an invalid / incomplete request (...index.php?option=com_ajax), you'll get a 404, which should be a 400 in my opinion.
TL/DR
For the time being and without a better explanation from an expert, I'm in favour of the proposed changes with the exception of the status 400.
Hackwar
- | Labels |
Added:
No Code Attached Yet
bug
Removed: ? |
||
From my point of view it's correct that
com_ajaxreturns a 200 as long as the componentcom_ajaxis not disabled and is doing its job as expected.Concerning
"success":trueversus"success":false: I don't know. I always check thedatabefore I go on. Therefore ???.