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
See discussion at https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/Dodomh9QZjk
Fixes an access issue where all public methods on FormField were allowed,
and not checked for $allowed_actions. Before this patch you could e.g.
call FormField->Value() on the first field by using action_Value.
Removes the following assertion because it only worked due to RequestHandlingTest_AllowedControllerExtension
*not* having $allowed_extensions declared: "Actions on magic methods are only accessible if explicitly allowed on the controller."
FIX: Ensure SSViewer::hasTemplate() is aware of themes.
To do this, RequestHandler::definingClassForAction() has been created, splitting out the code that looks up the class that defines a given action into its own method. This is then overridden in Controller to look at templates.
Without this change, a call to Cookie::get() immediately after Cookie::set()
won't return the value provided. This creates some unintuitive edge-cases,
although to date it looks like they have been worked around.
The patch doesn't have a test because our testing framework doesn't deal
with cookies well.
By default, the Session.timeout configuration option specifies the total
session time, regardless of the amount of activity. This change means
that the timeout specifies how long without any further dynamic requests
before the session cookie expires.
The way it does this is to re-set the session cookie expiry with a
subsequent Set-Cookie command each time a request that necessitates
a session is called.
Strictly speaking, it's a change in session timeout semantics, but I think
it's a good one, because total-session-time-regardless-of-activity is a
stupid timeout to include, and has more to do with the mechanics of the
internet than with application security requirements.
Cleanup of framework's use of @package and @subpackage labels and additional of labels for classes missing packages.
Moved all GridField related components to the one name.
Countless spelling fixes, grammar for other comments.
Link ClassName references in file headers.
In 3.0, doing $Action => SomeController would redirect all action requests
to that default controller. In 3.1, you need to do //$Action => SomeController
but it didnt work - those initial slashes broke matching
Regression introduced by Config API static changes.
Effectively meant that you can no longer log in to the CMS
since the cookie path is set for each URL individually...
This means that you dont have to worry about casting it
as HTMLText again when using the result in a template or other context
However in some situations code might be assuming it can
check with is_string, in which case you now need to use instanceof HTMLText
