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.
The functionality is easy to replicate in custom controllers,
and is too rarely used to be placed in core.
This also removes the `Member::is_repeat_member()` getter
and the `PastMember`/`IsRepeatMember` template globals.
See https://groups.google.com/forum/#!topic/silverstripe-dev/b8K3wU64TXg
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
urlRewriter will expect a callable as a second parameter,
but will work with the current api and simply raise a deprecation error.
HTTP::absoluteURLs now correctly rewrites urls into absolute urls. Resolves introduced in c56a80d6ce
HTTP::absoluteURLs now handles additional cases where urls were not translated.
Test cases for HTTP::absoluteURLs added for both css and attribute links.
Cleaned up replacement expression and improved documentation.
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.
