Make site secret available through public api

[jdalsem]

A few plugins need to use the site secret. Currently the function get_site_secret is access private. Is that on purpose? Do we need a new publicly available elgg_get_site_secret or a class function $site->getSecret()

[ewinslow]

Pointers to the plugins? Description of use cases?

The point of keeping things private is so that we don't over commit to a poorly designed API

[beck24]

I have a number of plugins that rely on it - usually for creating access tokens.
Here's a public one: https://community.elgg.org/plugins/1874086

[jdalsem]

same here; all kinds of tokens that needed to be unique per site, like:

• webservices tokens
• logged out access to private content (with a secure url)
• protecting upgrade/cron jobs
• invitation urls

There are ways around this, but that would mean to think of a way in every plugin. With the site secret there is an easy way to get a site specific random secret.

[mrclay]

We could do all those by exposing ElggCrypto::getHmac and ::areEqual in some way. It eliminates the risk of plugins doing something dumb with the key, and it nudges devs toward HMAC, which is the right tool for token (MAC) generation.

areEqual() does timing-attack-proof string comparison; unlikely to be a vector because the Elgg boot is so noisy, but why not do the right thing.

[mrclay]

Basically I'd rather provide a "token service" that provides and validates them.

[mrclay]

PR #8057

[mrclay]

What use case(s) require direct access to the site secret key? A key could be derived from the secret key via elgg_generate_mac('some unique string', 'sha256'), which would cause this to change when the secret key changes.

[jdalsem]

Closing this as #8057 removed the need to access the site secret publically