Either the forum’s search is insanely broken or I am just incapable of using it, but I reckon this bug should occur with ALL 3rd party frontend components.
The problem is as follows. I use a little hack in all my connectors. In the time of VisionCart we came across the problem that the $site_id may not be made public on the frontend, since you then can hack the backend (which wasn’t as secure as it now is). So, we created the fix when $_REQUEST[’ctx’] was equal to web, HTTP_MODAUTH would contain the $site_id.
Now, the $site_id is still present in the config, but has been adapted by the MODX’s session handler ($_SESSION[’modx.contextName.user.token’]). This is problematic, since MODX isn’t yet built when we need it for the connector (the connector creates it after HTTP_MODAUTH validation.
/* ensure headers are sent for proper authentication */
if (!isset($_SERVER['HTTP_MODAUTH']) && !isset($_REQUEST['HTTP_MODAUTH'])) {
$this->body = $modx->error->failure($modx->lexicon('access_denied'));
} else if (isset($_SERVER['HTTP_MODAUTH']) && $_SERVER['HTTP_MODAUTH'] != $siteId) {
$this->body = $modx->error->failure($modx->lexicon('access_denied'));
} else if (isset($_REQUEST['HTTP_MODAUTH']) && $_REQUEST['HTTP_MODAUTH'] != $siteId) {
$this->body = $modx->error->failure($modx->lexicon('access_denied'));
It get stuck after the 3rd else if check, where it is present AND doesn’t match the siteId, which is generated like so:
$siteId = $_SESSION["modx.{$this->modx->context->get('key')}.user.token"];
Aside from the strange code style, this is fine. The real problem is, we can’t access $_SESSION yet and the context siteId has a siteId_randomHash behind it, which is nowhere to be found.
Oh oh oh, what to do?
☆ A M B ☆
☆ A M B ☆
