I will have a trawl through the affected sites. It is possible I left the default .htaccess files in there, but I was 100% sure...up until 10 seconds ago that IIS would simply ignore .htaccess files. I know that we have no ISAPI filters in place to read or deal with them.
UPDATE: No luck there. There are no .htaccess files in there at all. can anyone point me to the code that gets run when a user tries to access a document in a protected document group, that might lead to a solution?
Hi there,
We do use one ISAPI filter, to re-write urls.
However to rule this out I set the site up again in IIS without access to the ISAPI filter. When I went to the page directly using the id the prompt appeared. So it would appear that its not the ISAPI filter that is to blame?
erm....my head scratching continues.
Can any of the MODx moguls tell me what piece of code fires when a page in a document group is accessed?
-
☆ A M B ☆
- 24,524 Posts
When you try to access a private page the parser triggers this function
function sendUnauthorizedPage() {
// invoke OnPageUnauthorized event
$_REQUEST['refurl'] = $this->documentIdentifier;
$this->invokeEvent('OnPageUnauthorized');
if ($this->config['unauthorized_page']) {
$unauthorizedPage= $this->config['unauthorized_page'];
} elseif ($this->config['error_page']) {
$unauthorizedPage= $this->config['error_page'];
} else {
$unauthorizedPage= $this->config['site_start'];
}
$this->sendForward($unauthorizedPage, 'HTTP/1.1 401 Unauthorized');
exit();
}
MODx has a setting for a page to use under these conditions, but your IIS is reacting to it before the request ever gets to MODx because of the 401 heading.
There is a forum section for IIS; I’m sure there’s a solution for this.
thanks scot, ill start a new thread in the IIS section and see if any of the guys over there can help!
