Updated: Comment #N

Problem/Motivation

Now that #2036259: Move $drupal_hash_salt to settings() is in. We can remove the call to drupal_get_hash_salt() in CsrfTokenGenerator and just inject settings instead. Added bonus; we can also remove the if (function_exists(...)) hack in CsrfTokenGeneratorTest. Nice.

Proposed resolution

Inject settings into the csrf_token service, and call settings->get('hash_salt') in the get() method instead.

Remaining tasks

Patch

User interface changes

None

API changes

None

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

damiankloip’s picture

FileSize
3.39 KB
damiankloip’s picture

Status: Active » Needs review
dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Perfect cleanup!

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

tstoeckler’s picture

drupal_get_hash_salt() throws an exception on an empty hash salt, which increases security as it does not allow misconfiguration. Are we fine with dumping that?

catch’s picture

Status: Fixed » Needs work

Er, no we're not. Reverted.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
4.88 KB
2.79 KB

Spoke to catch on IRC; Let's add this logic to the CsrfTokenGenerator for now.

damiankloip’s picture

damiankloip’s picture

Status: Needs review » Closed (duplicate)

Most of this is now obsolete, an the one small change can be rolled into #2207585: Find a new OO home for drupal_get_hash_salt(). As the usage example with the conversion.