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
BUG Fix incompatibility in Member_GroupList
Fix regressions in merges from 3.1
BUG Fix Security failing on test classes
BUG Fix postgresql compatibility
Clarify sql encoding of table names
Database abstraction broken up into controller, connector, query builder, and schema manager, each independently configurable via YAML / Injector
Creation of new DBQueryGenerator for database specific generation of SQL
Support for parameterised queries, move of code base to use these over escaped conditions
Refactor of SQLQuery into separate query classes for each of INSERT UPDATE DELETE and SELECT
Support for PDO
Installation process upgraded to use new ORM
SS_DatabaseException created to handle database errors, maintaining details of raw sql and parameter details for user code designed interested in that data.
Renamed DB static methods to conform correctly to naming conventions (e.g. DB::getConn -> DB::get_conn)
3.2 upgrade docs
Performance Optimisation and simplification of code to use more concise API
API Ability for database adapters to register extensions to ConfigureFromEnv.php
Default to "yyyy-MM-dd" for date format, and "H:mm" for time_format.
Switched to config API for setting/getting values.
Avoid using "MMM" in particular, since it causes
inconsistencies in month names between jQuery UI and Zend_Locale_Format.
Fixes https://github.com/silverstripe/silverstripe-cms/issues/544
This will resolve issues in cases where the site locale may be assigned a value that does not have an explicit translation. E.g. if the locale is en_NZ (and it's appropriate for this to be the assigned locale), Afrikaans will no longer be the default selected locale when creating members. Now en_US is chosen as a better fallback default.
This is a minor ease of use fix that means fewer CMS users can be accidentally created in Afrikaans within NZ based sites.
Test cases included.
Partially reverts b0f38f4990
which broke unit tests relying on the old entity name
in 3.1, where translations and the en.yml master file have been backported to.
Required to save/restore parts of the session information,
which Member nukes indiscriminately on logout.
Specific use case is restoring linkages to temporary databases
on Behat test runs.
If you fail your maximum login attempts and are locked out, further failed login attempts add to your already existing FailedLoginCount as it is only reset if you log in successfully. This means that if you're locked out, then try again, one failure will automatically lock you out again, regardless of what you set your max limit to.
Example:
lock_out_after_incorrect_logins: 3
FailedLoginCount: 0
The user fails three login attempts.
lock_out_after_incorrect_logins: 3
FailedLoginCount: 3
The user is now locked out.
Lockout time passes.
The user fails their 4th login.
lock_out_after_incorrect_logins: 3
FailedLoginCount: 4
This will continue to happen until the user successfully logs in, without giving them the pre-defined amount of login attempts again due to this condition being met after every incorrect login:
```php
if($this->FailedLoginCount >= self::config()->lock_out_after_incorrect_logins) {
```
FailedLoginTestCount Test Added
Adding a hook for registerFailedLogin so that it is possible to add some custom logic when a user fails to login
Also rearranged the write as this function could hit the DB up to 3 times. Now it will me 0 or 1 times.
Updates the CMS profile page and SecurityAdmin to give developers a few ways to customise the required fields.
Added extension hook updateValidator for getValidator for things like modules to inject required fields to go along with Injector for replacing the entire class for project specific use.
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
Due to the recent change of translations to transifex, some
locales changed their names, which prompted a fix to
i18n::get_available_translations() (see 00ffe7294).
This caused a regression where short locales are determined
from the YAML file names (e.g. "en"), but weren't matched up
with fully qualified locales from get_available_translations() (e.g. "en_US").
Since this list is used in the admin/myprofile dropdown for the Member.Locale value,
it didn't match up with any entries and defaulted to the first one ("Africaans").
Note that the behaviour of admin/myprofile is still a bit weird:
It defaults the locale on new members to the one set for the current administrator.
So if a site defaults to en_US in _config.php, but the admin happens to view
his backend in de_DE, all members he creates default to de_DE as well.
Thanks to @tractorcow for contributing and peer reviewing!
In 3.0 there was some confusion about whether DataLists and ArrayLists
were mutable or not. If DataLists were immutable, they'd return the result, and your code
would look like
$list = $list->filter(....);
If DataLists were mutable, they'd operate on themselves, returning nothing, and your code
would look like
$list->filter(....);
This makes all DataLists and ArrayList immutable for all _searching_ operations.
Operations on DataList that modify the underlying SQL data store remain mutating.
- These functions no longer mutate the existing object, and if you do not capture the value
returned by them will have no effect:
ArrayList#reverse
ArrayList#sort
ArrayList#filter
ArrayList#exclude
DataList#dataQuery (use DataList#alterDataQuery to modify dataQuery in a safe manner)
DataList#where
DataList#limit
DataList#sort
DataList#addFilter
DataList#applyFilterContext
DataList#innerJoin
DataList#leftJoin
DataList#find
DataList#byIDs
DataList#reverse
- DataList#setDataQueryParam has been added as syntactic sugar around the most common
cause of accessing the dataQuery directly - setting query parameters
- RelationList#setForeignID has been removed. Always use RelationList#forForeignID
when querying, and overload RelationList#foreignIDList when subclassing.
- Relatedly,the protected variable RelationList->foreignID has been removed, as the ID is
now stored on a query parameter. Use RelationList#getForeignID to read it.
Refactor the code to make it clear the distinction is made between a
plaintext token and a hashed version. Rename fields so it is more
obvious what is being written and what sent out to the user.
This reuses the salt and algorithm from the Member, which are kept
constant throughout the Member lifetime in a normal scenario. If they do
change, users will need to re-request so the hashes can be regenerated.
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.
CMSProfileController currently checks canView() which ensures that a logged in CMS
Member can access the profile controller, but when saving the record on Member_ProfileForm
there is no check for canEdit(), so extended permissions don't get respected.
This adds a check for canEdit() in Member_ProfileForm, and adds some functional tests
to check permissions.
MINOR Use injector for creating many many list objects
MINOR Use injector for creating objects from within the DataList
MINOR Use Injector::inst() for creating objects; cannot rely on this->injector being present due to many classes being created with 'new', so use inst() directly
MINOR Remove injector autoset property for now; automatically setting it breaks a few test cases that don't know about it for now, and it's not needed just yet
Renamed the Member::mapInGroups() to Member::map_in_groups() since it's a static method and throws deprecation message if using the old variant.
Rewrote the mapInGroups to use a more ORMy way of fetching Members for a set of groups and included a test for.
API CHANGE: Move Controller::PastMember() to Member::is_repeat_member() in code.
API CHANGE: Removed Controller::CurrentMember(), it was only ever intended as a template global provider.
API CHANGE Removed Member->setByCheckboxes()/setByCheckboxSetField(), Use setByIdList() and/or a CheckboxSetField instead
API CHANGE Removed Member->addManyByGroupID(), Use DataList->addMany() instead.
API CHANGE Removed Member->removeManyByGroupID(). Use DataList->removeMany() instead.
API CHANGE Removed Member->getGroupsFromIDs(). Use DataObject::get("Group")->byIds() instead.
API CHANGE Removed Member->addManyByCodename()/removeManyByCodename(). Don\'t rely on codename
