User tests: Successful: Unsuccessful:
Feature tracker item at http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8549&tracker_item_id=31800
Details:
This adds an extensible solution to provide Ajax support in core. It acts as an entry point for Ajax functionality in Joomla, designed to execute plugins following the onAjax[foo] naming convention or can return data from a [foo]Ajax method in a module's helper.php file. The goal is to provide an easier way to provide Ajax support where it doesn't already exist.
The source project for this extension can be found at https://github.com/betweenbrain/Joomla-Ajax-Interface with an exmaple module at https://github.com/betweenbrain/Ajax-Session-Module.
Related Joomla list thread at https://groups.google.com/d/msg/joomla-dev-general/i1syYWshGsY/3udixCaRnRAJ
GJ Matt!
Two things to notice here:
1. Correct your file's docblock to match Joomla's style.
2. I would use an Exception
with more specific messages instead of deprecated JError
:
// getAjax method does not exist
throw new BadMethodCallException(JText::_('Method does not exist'), 404);
// Helper file does not exist
throw new RuntimeException(JText::_('Helper file does not exist'), 404);
// Module not published
throw new RuntimeException(, JText::_('Module not published'), 404);
And may be it is better to use multilingual strings if we are using JText here ;)
as it AJAX request then something like next would be better I think:
$error = JText::_('ERROR_TEXT');
if($error) {
echo $error;
$app->close();
}
reason is that all method above will return HTML output, that can be difficult to debug in AJAX case
@Dmitry Thanks! And I will take a look at correcting the DocBlocks.
@Fedik and @Dmitry - Thank you. I was honestly struggling with how best to
approach the error handling. One reason for throwing a generic 404 error
page was in the case of if a malicious person is attempting to profile the
site by directly entering URLs that might correspond to an ajax request. My
thought was that case would be the same if attempting to access an
extension that or page that didn't exist. But, this does make debugging
more difficult and might be over thought. Since the scope for modules is
now limited, it might be okay to display a meaningful error message in the
case someone attempts to gain a response that isn't valid.
What do you think?
Best,
Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain
@Fedik sounds like you are right. In terms of AJAX this would be a better
approach that I've suggested.
—
Reply to this email directly or view it on GitHub.
Matt imo it's over thought. But definitely we need more opinions and thoughts here.
@betweenbrain said:
if a malicious person is attempting to profile the site by directly entering URLs that might correspond to an ajax request
I think that this person does not deserve on a meaningful error message ;) hehehe
for this case we realy need use a "token",
some more notices on the google group page ;)
@Fedik @b2z Consider me convinced regarding the error messages. I do like the idea of a solution that is easier to debug and provides more meaningful feedback.
@Fedik I haven't had a chance to draft a response for the Google group, but I would argue that tokens are something that should be handled by module or plugin. Reason being that there are cases where you do want external sites or persons to consume the Ajax response without authentication. One other thing to keep in mind is that access settings for modules are honored. Does that seem reasonable to you?
problem that I would not trust "access settings" for modules and plugins, because user/admin should check it each time when new module/plugin installed, and I am sure this will do almost no one ;)
as anyone can do request to index.php?option=com_ajax&module=foo
so in this way he can get data from any activate module by using brute force
if need allow the access from external sites, then we need think about some additional authentication
That is not an accurate statement about brute forcing any module.
Yes, anyone can request a response from any module, but only modules with a
helper.php file with a [foo]Ajax() method will return a result. Nicholas
from Akeeba did take a look and he was satisfied with this approach.
If I have time, I will set up a test site with CloudAccess so you can test
this.
Best,
Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain
On Aug 22, 2013 8:20 AM, "Fedik" notifications@github.com wrote:
problem that I would not trust "access settings" for modules and plugins,
because user/admin should check it each time when new module/plugin
installed, and I am sure this will do almost no one ;)as anyone can do request to index.php?option=com_ajax&module=foo so in
this way he can get data from any activate module by using brute forceif need allow the access from external sites, then we need think about
some additional authentication—
Reply to this email directly or view it on GitHub#1778 (comment)
.
Just to be sure that we're looking at the same code, the helper files is included at https://github.com/betweenbrain/joomla-cms/blob/9a5d53ef76de789d84573a8fd41db695525b1977/administrator/components/com_ajax/ajax.php#L46 and method called at https://github.com/betweenbrain/joomla-cms/blob/9a5d53ef76de789d84573a8fd41db695525b1977/administrator/components/com_ajax/ajax.php#L57
sorry, I am missed [foo]Ajax()
No problem at all. I sincerely appreciate the feedback and review. Security
is always an important factor and my goal is to provide a flexible, yet
secure, solution. Thanks again!
Best,
Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain
On Aug 22, 2013 8:44 AM, "Fedik" notifications@github.com wrote:
sorry, I am missed [foo]Ajax()
—
Reply to this email directly or view it on GitHub#1778 (comment)
.
Need the component's XML file added here.
You need to add the sql in the 3.2.0.sql files. I know this is going to get messy with there being a number of components and extensions coming in (potentially) but let's at least get a first pass.
Also remember that assets in the sample data files need to be considered.
There is a bug in ajax interface if module is assigned only to selected menu items and ajax returns an error:
Module mod_xxx is not published, you do not have access to it, or it\'s not assigned to the current menu item
This helper
$moduleObject = JModuleHelper::getModule('mod_' . $module, null);
always has
$moduleObject->id = 0
if you do not pass request variable with Itemid to which module is assigned.
So it is required to pass Itemid of currently viewed page to ajax request.
This makes almost impossible to use ajax request on back-end.
I think that also disabled module should have possibility to make ajax request on back-end.
If you want to have ajax functionality in module configuration then now it would not work for disabled module and assigned for selected menu items
Updated documentation for usage at https://github.com/betweenbrain/Joomla-Ajax-Interface/blob/master/README.md