next »

[lossendae]

Hello,

After many hours of hairs tearing and forums reading leading to nothing, i might have find a bug with modx connector which cause ajax call to fail when sended from IE8 (with jQuery, didn't test with others libs);

Using the default connector as in the docs:

Code:

<?php

require_once dirname(dirname(dirname(dirname(__FILE__)))).'/config.core.php';
require_once MODX_CORE_PATH.'config/'.MODX_CONFIG_KEY.'.inc.php';
require_once MODX_CONNECTORS_PATH.'index.php';

require_once MODX_CORE_PATH.'components/mycomponent/model/mycomponent/mycomponent.class.php';
$modx->mycomponent = new MyComponent($modx);

if (isset($_REQUEST['resource'])) {
    $modx->resource = $modx->getObject('modResource',$_REQUEST['resource']);
}

/* handle request */
$path = $modx->getOption('processors_path',$modx->mycomponent->config,$modx->getOption('core_path').'components/mycomponent/processors/');
$modx->request->handleRequest(array(
    'processors_path' => $path,
    'location' => '',
));

I noticed that nothing happenned after this line (only with IE):

Code:

<?php

require_once MODX_CONNECTORS_PATH.'index.php';

The script literally die with the file located in "connectors/index.php" on line 44 (beta-5) with checkPolicy().

Code:

<?php

/* initialize the proper context */
$ctx = isset($_REQUEST['ctx']) && !empty($_REQUEST['ctx']) ? $_REQUEST['ctx'] : 'mgr';
$modx->initialize($ctx);
if (defined('MODX_REQP') && MODX_REQP === false) {
} else if (!$modx->context->checkPolicy('load')) { die(); } //This is the incriminated line

The odd part is that it works in all other browser.
And the right context is well sended since i can echo it before the line who cause the crash.

Is this a bug and should be in Jira or is there a problem with my localhost install (Wamp)?

[lossendae]

I've come across an interesting answer from OpenGeek http://modxcms.com/forums/index.php/topic,40611.msg245063.html#msg245063 which mentionned what checkPolicy does.

So i just logged in the manager from IE8 and the script worked.
Note that, i am also loggout of the manager in both Chrome and FF and the script failed at the same point on those browsers.

Now, that is surprising, does it means that we can't use Ajax with anonymous users?

[OpenGeek]

Now, that is surprising, does it means that we can't use Ajax with anonymous users?

It means you have to have a policy that gives anonymous users whatever specific permissions you want them to have. You obviously don't want to give anonymous users the ability to delete content or move Resources (for instance). So craft a policy that gives anonymous users just the permissions you want them to have when accessing your connectors from a specific Context.

[lossendae]

It means you have to have a policy that gives anonymous users whatever specific permissions you want them to have. You obviously don't want to give anonymous users the ability to delete content or move Resources (for instance). So craft a policy that gives anonymous users just the permissions you want them to have when accessing your connectors from a specific Context.

Like Quip Debug user which return an anonymous user (but only when Debug mode si on)

[OpenGeek]

I'm not familiar with Quip at all, but IMO, all public AJAX interaction should be done via Resources and Snippets for components outside of the mgr context. Adding new gateways for AJAX targets is unnecessary and will potentially lead to unintended security risks.

[lossendae]

Quip does that.

The Ajax call pass the context "web" as a parameter to the connector. Then we add to do some security checking after.

It may not be the good way to proceed or i don't understand it well enough, see the default connector:

Code:

<?php
/* Load custom Quip defines and modx object */
require_once dirname(dirname(dirname(dirname(__FILE__)))).'/config.core.php';
require_once MODX_CORE_PATH.'config/'.MODX_CONFIG_KEY.'.inc.php';
require_once MODX_CONNECTORS_PATH.'index.php';

require_once MODX_CORE_PATH.'components/quip/model/quip/quip.class.php';
$modx->quip = new Quip($modx);

if (isset($_REQUEST['resource'])) {
    $modx->resource = $modx->getObject('modResource',$_REQUEST['resource']);
}

/* handle request */
$path = $modx->getOption('processors_path',$modx->quip->config,$modx->getOption('core_path').'components/quip/processors/');
$modx->request->handleRequest(array(
    'processors_path' => $path,
    'location' => '',
));

Maybe it's a simple connector only for the example.

[Ricjustsaid]

I'm not familiar with Quip at all, but IMO, all public AJAX interaction should be done via Resources and Snippets for components outside of the mgr context. Adding new gateways for AJAX targets is unnecessary and will potentially lead to unintended security risks.

I think a question worth asking here might be whether we should be using connectors for our AJAX requests at all, or should we simply send a request to the current resource with an "ajax" flag in the request URI to determine what data should be returned (JSON, or the fully MODx-ified page)? Quip does the former, and all AJAX requests go through an external connector file. Is there a standard or preferred way of handling AJAX requests in non-manager contexts?

[OpenGeek]

I think a question worth asking here might be whether we should be using connectors for our AJAX requests at all, or should we simply send a request to the current resource with an "ajax" flag in the request URI to determine what data should be returned (JSON, or the fully MODx-ified page)? Quip does the former, and all AJAX requests go through an external connector file. Is there a standard or preferred way of handling AJAX requests in non-manager contexts?

The confusion is that a Resource in MODx with a Snippet that returns JSON or HTML or something, is no different than calling an external PHP "connector" for the AJAX request (except it has all the benefits of going through the MODx gateway rather than handling everything itself).  And though I don't typically use the current resource with an AJAX flag, I do use separate dedicated AJAX Resources with their own aliases and URLs for front-end AJAX work. The manager is a different animal altogether and that is where "connectors" come into play IMO.

[Ricjustsaid]

I think a question worth asking here might be whether we should be using connectors for our AJAX requests at all, or should we simply send a request to the current resource with an "ajax" flag in the request URI to determine what data should be returned (JSON, or the fully MODx-ified page)? Quip does the former, and all AJAX requests go through an external connector file. Is there a standard or preferred way of handling AJAX requests in non-manager contexts?

The confusion is that a Resource in MODx with a Snippet that returns JSON or HTML or something, is no different than calling an external PHP "connector" for the AJAX request (except it has all the benefits of going through the MODx gateway rather than handling everything itself).  And though I don't typically use the current resource with an AJAX flag, I do use separate dedicated AJAX Resources with their own aliases and URLs for front-end AJAX work. The manager is a different animal altogether and that is where "connectors" come into play IMO.

After thinking about it, it seems like this is the way to go with frontend AJAX requests. Using the external connector method, you need to take care that the request is only handled/executed for authorized users (well, for any kind of system management requests). Plus, it seems like it'd be far more difficult to deal with snippet parameters that have have been customized in the snippet call. One issue with using the current resource as the AJAX target is the fact that any snippet calls or other placeholders preceding your own snippet are going to be executed before outputting your AJAX content, which almost seems like it defeats the purpose of using AJAX in the first place! Using a separate resource just for AJAX requests for each component seems like a good middle ground - efficient, while allowing the user to customize the snippet properties and access policy right from the manager.

Thanks Opengeek!