* WIP Backport of querystring work to 3.x
* Remove dataextension requirement
* Fix up bootstrapping
* more backporting
* Bug fix some tests
* Fix up some tests
* Fix support for custom stages
Don't set empty stage
* Better cache typehint
* Make sure useDraftSite(false) re-enables secure site
* Remove unnecessary guard around controller property
I've decoupled `Cookie` from the actual act of setting and getting
cookies. Currently there are a few limitations to how Cookie works that
this change mitigates:
0. `Cookie` currently changes the super global `$_COOKIE` when setting
to make the state of an application a bit more managable, but this is
bad because we shouldn't be modifying super globals
0. One can't actually change the `$cookie_class` once the
`Cookie::$inst` has been instantiated
0. One can't test cookies as there is no class that holds the state of
the cookies (it's just held in the super global which is reset as part
of `Director::test()`
0. One can't tell the origin of a cookie (eg: did the application set it
and it needs to be sent, or did we receive it from the browser?)
0. `time()` was used, so testing was made difficult
0. There was no way to get all the cookies at once (without accessing
the super global)
Todos are on the phpdoc and I'd like to write some tests for the backend
as well as update the docs (if there are any) around cookies.
DOCS Adding `Cookie` docs
Explains basic usage of `Cookie` as well as how the `Cookie_Backend`
controls the setting and getting of cookies and manages state of sent vs
received cookies
Fixing `Cookie` usage
`Cookie` is being used inconsistently with the API throughout framework.
Either by not using `force_expiry` to expire cookies or setting them to
null and then expiring them (which is redundant).
NEW `Director::test()` takes `Cookie_Backend` rather than `array` for `$cookies` param
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
Anchors should never make it to the server when they are in the browser URL bar, however tests are slightly different and some `Link()` functions may return a URL anchor. Instead of every test checking a link and stripping the anchor, I feel the Director::test() function should strip them off.
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
