[2013-02-28] Require ADMIN for ?flush=1 (stop denial of service attacks)

[silverstripe-issues]

created by: @chillu (ischommer) created at: 2013-02-28 original ticket: http://open.silverstripe.org/ticket/8290

---

See https://groups.google.com/forum/?fromgroups=#!topic/silverstripe-dev/XDUDZtr9Gbk

Already enforced for flush=all, but not for flush=1.

Ensure that you can execute the flush unauthenticated if Database::is_ready() == false, because otherwise we're getting into a chicken and egg situation: Can't log in due to stale manifest (and SQL errors etc), can't clear stale manifest because not logged in.

[tractorcow]

@hafriedlander Yep it's fixed!

[camspiers]

On 3.1 @ 541436f When running ?flush=1 in dev mode after I have renamed a module, I get this:

And then if I look in my php error log I have:

[24-Jul-2013 13:46:05 Pacific/Auckland] PHP Warning:  require_once(/Users/cameron/modules/silverstripe/testmodule/_config.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /Users/cameron/modules/silverstripe/framework/core/manifest/ConfigManifest.php on line 141
[24-Jul-2013 13:46:05 Pacific/Auckland] PHP Fatal error:  require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/Users/cameron/modules/silverstripe/testmodule/_config.php' (include_path=...) in /Users/cameron/modules/silverstripe/framework/core/manifest/ConfigManifest.php on line 141
[24-Jul-2013 13:46:05 Pacific/Auckland] PHP Warning:  Cannot modify header information - headers already sent in /Users/cameron/modules/silverstripe/framework/core/startup/ParameterConfirmationToken.php on line 97

[hafriedlander]

@camspiers Argh. You will still get the errors in the log, as ErrorControlChain doesn't suppress logging them. You shouldn't get that last warning though - looks like something PHP 5.3 specific where PHP thinks headers have already been sent. Looking now.

[camspiers]

Should probably mention that it doesn't flush. So it isn't just that I get the errors.

On Wednesday, 24 July 2013, Hamish Friedlander wrote:

@camspiers https://github.com/camspiers Argh. You will still get the errors in the log, as ErrorControlChain doesn't suppress logging them. You shouldn't get that last warning though - looks like something PHP 5.3 specific where PHP thinks headers have already been sent. Looking now.

— Reply to this email directly or view it on GitHubhttps://github.com/silverstripe/silverstripe-framework/issues/1692#issuecomment-21459262 .

[hafriedlander]

Yeah, unless you get a flushtoken, it won't flush. Problem though: I manually removed my silverstripe cache as part of testing, and now I can't replicate the issue even in PHP 5.3. I did notice that if you run out of memory because of a corrupt cache you can't flush, but I don't think that's what you're seeing.

[ss23]

I suspect some of these changes are the cause of issues I'm having on latest 3.1, specifically, the changes to not catch more errors.

Previously, working was

$foo = DBField::create('HTMLText', null);
echo $foo;

Because it's a fatal catchable (Catchable fatal error: Method HTMLText::__toString() must return a string value), it was being caught and ignored. Now it's not caught, and causing a fatal error in the script.

While I like getting this change into 3.1, I would prefer there weren't BC breaks like this so close to a release. Can we get that commit changed/reverted and fix it in 3.2 instead? (I think it does need to be fixed, of course).

[camspiers]

I'll do some more digging for you. Hopefully it is user error on my end.

On Wednesday, 24 July 2013, Hamish Friedlander wrote:

Yeah, unless you get a flushtoken, it won't flush. Problem though: I manually removed my silverstripe cache as part of testing, and now I can't replicate the issue even in PHP 5.3. I did notice that if you run out of memory because of a corrupt cache you can't flush, but I don't think that's what you're seeing.

— Reply to this email directly or view it on GitHubhttps://github.com/silverstripe/silverstripe-framework/issues/1692#issuecomment-21459616 .

[hafriedlander]

@ss23 that should be fixed as of this release - it only catches fatal errors that aren't otherwise caught by the error handling system.

Can we get that commit changed/reverted and fix it in 3.2 instead?

We need to fix this issue before 3.1.0. In fact, this same fix is being applied to 2.4 and 3.0 as well. There are alternative solutions with varying impacts (see https://github.com/silverstripe/silverstripe-framework/issues/1692#issuecomment-20715207) but I can't see us releasing 3.1.0 without this being addressed somehow.

[ss23]

@hafriedlander Ah, sorry, I see I wasn't running on the very latest 3.1. Indeed, looks like it's back to working now.

[hafriedlander]

@camspiers Cool, thanks. I've put my experimental changes on a personal branch at https://github.com/hafriedlander/silverstripe-framework/commits/fix/flush_31 - it fixes issues related to running out of memory, and as a last ditch if headers_sent is true it'll just dump a link rather than try and send headers anyway.

[camspiers]

Yuss!. I figured it out. It was my setup that was causing in. I have php_value auto_prepend_file "/Users/cameron/Sites/xhgui/external/header.php in my .htaccess and that was outputting something (no idea what).

Sorry about that Hamish.

What do you think of the use of meta refresh for the case where headers have been sent?

[hafriedlander]

Probably not a bad idea - there'll always be someone who accidentally leaves a space before the opening <?php stanza somewhere, and ugly is better than WSOD.

[bummzack]

@hafriedlander Oh man, I don't envy you. You seem to have opened pandoras box with these changes :-) Just wanted to let you know that everything works fine now with a symlinked install. Thanks for all your work on this.

[UndefinedOffset]

Shouldn't the core also check for admin on the Image class https://github.com/silverstripe/silverstripe-framework/blob/3.1/model/Image.php#L415 seeing how that can also be very taxing?

[UndefinedOffset]

Never mind... as simon_w pointed out in the channel the flush key is being unset https://github.com/silverstripe/silverstripe-framework/blob/3.0/main.php#L108-L110

[chillu]

This has been released as part of 3.1.0-rc1