BUG Disabled disruptive test case in DirectorTest
API RequestProcessor and VersionedRequestFilter now both correctly implement RequestFilter
Better PHPDoc on RequestFilter and implementations
BUG Resolve issue with DirectorTest breaking RequestProcessor
Injector::nest and Injector::unnest are introduced to better support sandboxing of testings.
Injector and Config ::nest and ::unnest support chaining
Test cases for both Injector::nest and Config::nest
SS_HTTPRequest can be read like an array, e.g. echo $request['a'], but cannot be written like an array, e.g. $request['a'] = 5; Added comment to caution people.
See line 375:
==================================================================
/**
* @ignore
*/
public function offsetSet($offset, $value) {}
/**
* @ignore
*/
public function offsetUnset($offset) {}
==================================================================
Might be good to write something about how you are supposed to modify a request, or what you are supposed to do instead (a redirect?).
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.
A service factory can be used for creating instances where a non-trivial
construction process is required. This is done by adding a `factory`
key to the service definition.
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
This ensures that the correct stage is selected, even if the request
does not come through the model as controller system. This fixes an
issue where custom controllers would always be on the "Stage" stage.
This ensures that the correct stage is selected, even if the request
does not come through the model as controller system. This fixes an
issue where custom controllers would always be on the "Stage" stage.
When using Controller::join_links to join two links with identical query
params, both query params would be used in the result, ending up with
links that look like `../edit/show/14?locale=en_NZ&locale=mi_NZ`
This patch eliminates duplicate query params, so only the last one
for any key is present in the output.
Currently IE6-8 will refuse to download files over HTTPS with default
Framework settings.
Currently the HTTP::add_cache_headers competely overrides Cache-Control
headers on each request, so there is no way to inject custom headers
from the API-consuning methods.
Also of note: adding no-store header also fixes the issue but will
prevent proxies from caching the request body (which they do when using
no-cache). So the setting max-age to some low number is a better choice
here.
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
Session tracks the user agent in the session, to add some detection of
stolen session IDs. However this was causing a session to always be
created, even if this request didnt store any data in the session.
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
