Example: you have a site in a sub-directory off the webroot, you call
->Link() on a SiteTree record, which returns "/[sitedir]/my-page", and
you pass this URL to Director::test(). It's a valid URL, but
Director::test() will throw a 404.
Director::test() should be ensuring that all URLs passed to it are
properly made relative, not just in the case where it thinks the URL
is absolute.
When the email sender makes the links absolute, it can't handle empty `href` or `src` attributes as there's no expectation that the string length could be 0
Move functionality from static start and destroy functions into instance
methods, allowing these to be overloaded. This works the same way as
calling Session::set() which then in turn calls inst_set()
Additionally use Injector to create the default Session instance to
allow the class to be swapped out.
BUG Disabled disruptive test case in DirectorTest
API RequestProcessor and VersionedRequestFilter now both correctly implement RequestFilter
Better PHPDoc on RequestFilter and implementations
Director::test() don't set the HTTP_HOST with the port number if that has been set.
Later call to Director::makeRelative() will return wrong value because of the strict string matching
(http://localhost/ != http://localhost:8000)
This bug affects all modules that are using Director::test in CLI where the $_FILE_TO_URL_MAPPING
have been set to use a domain with a port in it, i.e. static publishers.
De-facto standard for identifying the originating protocol of an HTTP request through a reverse proxy or load balancer.
http://www.geekisp.com/faq/6_65_en.html
If any of the functionality triggered by Director::isDev()
was causing deprecation errors, the system would go into
an infinite loop. Since the only way to cause this is the DB
checking functionality, we disable that for Deprecation.
Side effect of this change: You can't show deprecation notices
on a live site by forcing the session into dev mode.
Session::$cookie_secure adds the secure property to the session Set-Cookie
command, so that the browser wouldnt send it to the server over an unencrypted
link. However the server would still send the cookie to the browser
unencrypted. Also Sessions would stop working properly in HTTP,
but SilverStripe needs them for several things, such as form validation
This patch effectively causes HTTP and HTTPS requests to each have
their own session when cookie_secure is true. The two sessions are
independant from each other, so information set in the session via
HTTPS is safe from attacks on the session via HTTP, but parts
of the site that use HTTP and the session will still work
If you have a Varnish box in front of a SilverStripe install, and
you call forceSSL, the Vary header wouldnt get sent. As a result
Varnish would respond with the same redirect reponse after the
redirect, leading to an infinite loop
This reverts commit 356a367eb5.
We can't use headers_sent() to determine an accurate
content length, since PHP defaults to buffering a couple of bytes
even without ob_start() (see "output_buffering" setting).
This makes the patch harmful, since it breaks any responses relying
on more structure data, like removing closing brackets from JSON.
Which in turn breaks the CMS in horrible ways (see #8010).
See #7574 for context.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
