A potential account hijacking may happen if an attacker has physical access to
victim's computer to perform session fixation. Also possible if the targeted application contains an XSS vulnerability.
Requires the victim to click the password reset link sent to their email.
If all the above happens, attackers may reset the password before the actual user does that.
A potential account hijacking may happen if an attacker has physical access to
victim's computer to perform session fixation. Also possible if the targeted application contains an XSS vulnerability.
Requires the victim to click the password reset link sent to their email.
If all the above happens, attackers may reset the password before the actual user does that.
* NEW Make resources dir configurable.
* Removing reference to old `resources` and updating doc #8519
* Rrtarget to 4.4 release.
* DOC Reference SS_RESOURCES_DIR in Environment doc.
* API Add a Resources method to SilverStripe\Core\Manifest\Module to read the resources-dir from composer.json
* Clean up reference to SS_RESOURCES_DIR env var
* Set default resources-dir
* Update test to use RESOURCES_DIR const in expected resource url method
* Correcting typos
Co-Authored-By: maxime-rainville <maxime@rainville.me>
* MINOR Correctubg minor typos
* DOCS Document the intricacies of exposing static assets.
- Replace session name lookup with function to also check secure cookies
- Added timeout which defaults to 0 (same as PHP)
- Removed php7 style of session_start from PR
- moved session_start into headers sent block to prevent warnings.
If a session already exists, and Session::start() isn’t called until
after a large enough block of content is output, then headers_sent()
will be false. The previous code prevented the session from being
started in this case. That might makes sense for the creation of a new
session, but it prevent legitimate access to an existing session.
This mostly manifested when running debugging tools such as showqueries,
which may output content before the session is started.