Problem/Motivation
Multisite relies on the locally set ApacheSolr site hash to determine which site it is currently looking at. This is a random six-digit string.
While this string is intended to be unique per site, in practice this is not the case, as the hash will be shared across any sites which duplicate the database. This includes development sites, for which this may be desirable, and sites which simply result from a duplicated database. While the latter is not optimal from a development perspective, it does occur.
Additionally, should this value get out of sync, or be changed, it cannot be predictably reset, since it is randomly regenerated.
Proposed resolution
Implement hash generation for multisite indexes based on the site URL, and allow the user to regenerate this hash if required. Don't replace existing hashes unless the user forces it, but warn on the Multisite admin page when this might be beneficial.
Remaining tasks
None, patch supplied.
User interface changes
The Multisite overview page will require a minor redesign to accommodate the additional hash checking, hash information, and regeneration options.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#2 | 2225181-1-validate-hashes.patch | 15.3 KB | xtfer |
Comments
Comment #1
xtfer CreditAttribution: xtfer commentedComment #2
xtfer CreditAttribution: xtfer commentedPatch attached.
Comment #3
xtfer CreditAttribution: xtfer commentedAdditionally, this patch is blocked by and requires #2224325: Bundle exclusion breaks when indexed bundles change.
Comment #4
Dane Powell CreditAttribution: Dane Powell commentedWhat if a single site is accessible by multiple URLs? For instance www.example.com (public-facing) and edit.example.com (for authenticated users). Seems like this would create multiple hashes for the same site.