095 RC2 Too many forward attempts issue

There is a very nice "Locking" feature available for every snippet/chunk/plugin/module, that is highlighted in screenshot below.

Just use it and then you will be only one who can ........... ...

Ok, I’ve just gotten bitten by this same issue, both sites are using revision 2017. They both had a bogus "unauthorized" page assignment. I’ve fixed one and left the other; I will closely monitor them (they are actually hosted on the same server) and the server logs to see if I can see exactly where this is coming from.

Quote from: sottwell at Nov 26, 2006, 01:15 PM

Ok, I’ve just gotten bitten by this same issue, both sites are using revision 2017. They both had a bogus "unauthorized" page assignment. I’ve fixed one and left the other; I will closely monitor them (they are actually hosted on the same server) and the server logs to see if I can see exactly where this is coming from.

I can tell you where it’s coming from; sendForward(). If you have a bogus error_page or unauthorized_page setting, and you attempt to access a page that doesn’t exist or is protected, it’s gonna loop until it hits the maximum forward attempts, and then it’s going to throw this error, to prevent an infinite loop from occurring. Additional checks have been added to the manager to warn of settings that can potentially cause this situation, and perhaps we can find a better way to resolve this problem (but still record it in the log) by trying to go to the site_start if we hit the maximum forward attempts. But this still could be a problem if the site_start is not accessible for some reason, and I currently cannot envision a better way to handle that scenario. Let me know if you have any ideas...

Yes, I could guess that much. My question is, what was so suddenly causing so many "unauthorized" hits? Is this somehow related to hacking attempts? I mean, I was coding a module just a few days ago, and generating a few system events with the bugs in the code, and this wasn’t there. Now suddenly I’ve got 132Mb of data in the system event table! And it happened at the same time to both sites ( I had mis-installed the new SkinGraft, and generated a few events before I fixed it, so I know the event log was clean then!).

Ok, just as I suspected. A few days ago some idiot tried to use the mcpuk hack, and had a bad URL, attempting to read the connectors/php/Command directory, resulting in a rash of 403 errors, since the server is set to refuse directory listing and there is no index page in that directory. And with my bad error page assignment, it was loading up the system events. Now I’m satisfied.

Quote from: OpenGeek at Nov 26, 2006, 03:00 PM

Additional checks have been added to the manager to warn of settings that can potentially cause this situation, and perhaps we can find a better way to resolve this problem (but still record it in the log) by trying to go to the site_start if we hit the maximum forward attempts. But this still could be a problem if the site_start is not accessible for some reason, and I currently cannot envision a better way to handle that scenario. Let me know if you have any ideas...

Well, actually a couple of ideas did occur to me. In the manager, attempting to delete a document that is set to be site_start throws an error. The same could be done for the 403 and 404 error pages. I know I got in this situation from installing the demo site, then deleting the 403 page since it’s set to be one of the two login pages. The 404 document is clearly labeled as such in the Tree, while the 403 page isn’t, and is easy to overlook.

Another idea is a bit more complicated. To set a parent container, there is no input field, just the option to click on a document in the Tree. What if the same method were used to set start_doc, as well as the 404 and 403 pages in the Configuration? That way there would never be typos and other errors assigning non-existent pages to those.
Alternatively, on saving the configuration checks could be made on those three fields to make sure those documents do exist; perhaps using the new DocumentMap array.

I suppose the same should be done with the site_unavailable page (if set at all) as well.

Another idea just occured to me; if it redirects three times and fails, could it then trigger the site unavailable message?

Quote from: sottwell at Nov 27, 2006, 01:22 AM

In the manager, attempting to delete a document that is set to be site_start throws an error. The same could be done for the 403 and 404 error pages.

As well as unpublishing start and error pages, or setting their access permission to private.. (what I did) Sounds stupid maybe, but it would have saved me (and others?) a small headache

More off topic, I still don’t get how I can set public pages to be only editable by a certain role, i.e. ’shop managers’ or ’content editors’. Is this possible?

Publicly viewable pages are a totally different matter from editable pages. One works with web user groups, the other works with manager user groups. You can give a document a document group, then connect that document group to a manager user group. Then only managers belonging to that group can edit it, but all web visitors can still see it.

Quote from: OpenGeek at Nov 26, 2006, 03:00 PM

I can tell you where it’s coming from; sendForward(). If you have a bogus error_page or unauthorized_page setting, and you attempt to access a page that doesn’t exist or is protected

Hello

I’ve waited a wail to see how it live ...
My error_page is (usually) functionning well ... it’s an "home made page" But i’ve tested it
http://www.parapentiste.info/index?id=7

the unauthorized_page setting leads to the "request an account" = http://www.parapentiste.info/index?id=5
No visitor should arrive there as I don’t use any private page.

(I give you page Id as I once again tested this morning, according to the id given in configuration page)

But I’m still having those pages of errorlogs :S
It appears ony in the morning... which seem a nice clue isn’t it ? what appens early in the morning ?
* do MODx make a renewal of it’s cache ?
* I have to verify but I think that OVH make a restart of it’s SQL server (but as I have much more access to the forum, it should be only sensible on the forum (~3000-4500 pages/day instead of only 20-30 for MODx part) and I know SMF send me email when it has problem accessing database (and it manages this for being transparent for visitors)
* what else can append (only in the morning) ?

Quote from: piwaille at Nov 30, 2006, 02:38 AM

But I’m still having those pages of errorlogs :S
It appears ony in the morning... which seem a nice clue isn’t it ? what appens early in the morning ?
* do MODx make a renewal of it’s cache ?
* I have to verify but I think that OVH make a restart of it’s SQL server (but as I have much more access to the forum, it should be only sensible on the forum (~3000-4500 pages/day instead of only 20-30 for MODx part) and I know SMF send me email when it has problem accessing database (and it manages this for being transparent for visitors)
* what else can append (only in the morning) ?

OVH?

All i can think of is that’s when the hackers come out to play and maybe they are hitting URLs within your site that are triggering Unauthorized responses? Otherwise, perhaps there is another bad url, maybe within your SMF theme or something, that is getting called a lot and triggering this. But again, if you have no permissions restricting access to those pages, and they are configured properly, there should not be an error from this.