☆ A M B ☆
<?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' => '',
));
<?php require_once MODX_CONNECTORS_PATH.'index.php';
<?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
☆ A M B ☆
MODX Staff
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.
Now, that is surprising, does it means that we can’t use Ajax with anonymous users?
☆ A M B ☆
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.
MODX Staff
☆ A M B ☆
<?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' => '',
));
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?
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.
MODX Staff
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.
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?
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!
Quote from: Ricjustsaid at Jan 15, 2010, 09:49 PMThe 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.
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?
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. 
