Making WordPress.org

Opened 5 years ago

Closed 22 months ago

Last modified 22 months ago

#3678 closed defect (bug) (wontfix)

Add WP_CACHE_KEY_SALT to WordPress.org secret-key service

Reported by: kraftbj's profile kraftbj Owned by:
Milestone: Priority: normal
Component: API Keywords:
Cc:

Description

Originally posted by @paulschreiber at https://core.trac.wordpress.org/ticket/44425 . Cross-posting here for the API side of the request.

Currently, the WordPress.org secret-key service

https://api.wordpress.org/secret-key/1.1/salt/

generates AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT.

It would be helpful if it also generated WP_CACHE_KEY_SALT. That way, people who install the object-cache.php drop-in would be less likely to experience unexpected behaviour.

See also: https://github.com/Automattic/wp-memcached/issues/31

Change History (8)

#1 @obenland
5 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

I think I agree with Otto's comment here. If someone is qualified enough for a drop-in, I think it's reasonable to expect them to also define that constant.

#2 @paulschreiber
4 years ago

I think I agree with Otto's comment here. If someone is qualified enough for a drop-in, I think it's reasonable to expect them to also define that constant.

This argument is like saying "real programmers don't use syntax coloring." No purity tests, please.

I had to update 20 sites today ... by hand ... because the salts API (and therefore wp cli, which uses it) still doesn't support WP_CACHE_KEY_SALT.

#3 @nickchomey
22 months ago

I'd also love to see this

#4 follow-up: @dd32
22 months ago

Just confirming we won't be adding support for WP_CACHE_KEY_SALT here.

The API is designed for Cores use, and does not add constants required by 3rd party items.

Specifically regarding WP_CACHE_KEY_SALT though, you really want to ensure it's a short string (and not a purely random string) as in many cache backends there's a key length limit.

#5 @paulschreiber
22 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Can you at least make WP_CACHE_KEY_SALT available via a query parameter?

Memcached is only barely a "third-party" item -- it's made by Automattic!

#6 @dd32
22 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

No, the API isn't the place for it.

Memcached is only barely a "third-party" item -- it's made by Automattic!

Automattic doesn't get preferential treatment from WordPress.org. (despite being my employer, and sponsoring multiple people to work on WordPress.org and related projects)

Last edited 22 months ago by dd32 (previous) (diff)

#7 @dd32
22 months ago

Also noting for others in the future, you can set it automatically via WP-CLI something similar to this:

wp config set WP_CACHE_KEY_SALT `cat /dev/urandom | tr -dc 'a-z0-9' | head -c10`

(That was the first command to get a short random string I saw on Google, replace it with something that makes sense for your environment)

Last edited 22 months ago by dd32 (previous) (diff)

#8 in reply to: ↑ 4 @nickchomey
22 months ago

Replying to dd32:

Specifically regarding WP_CACHE_KEY_SALT though, you really want to ensure it's a short string (and not a purely random string) as in many cache backends there's a key length limit.

Yeah, on further consideration I already decided to just use the site's domain as the key salt - makes it easy to set as well as navigate the redis database. Best to leave this closed, sorry for raising the dead.

Note: See TracTickets for help on using tickets.