revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-18 21:02:41 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/resources/sql/patches/104.searchkey.sql

13 lines
352 B
MySQL
Raw Normal View History

Use a unique random key to identify queries, not a sequential ID Summary: We save search information and then redirect to a "/search/<query_id>/" URI in order to make search URIs short and bookmarkable, and save query data for analysis/improvement of search results. Currently, there's a vague object enumeration security issue with using sequential IDs to identify searches, where non-admins can see searches other users have performed. This isn't really too concerning but we lose nothing by using random keys from a large ID space instead. - Drop 'authorPHID', which was unused anyway, so searches can not be personally identified, even by admins. - Identify searches by random hash keys, not sequential IDs. - Map old queries' keys to their IDs so we don't break any existing bookmarked URIs. Test Plan: Ran several searches, got redirected to URIs with random hashes from a large ID space rather than sequential integers. Reviewers: arice, btrahan Reviewed By: arice CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1587
2012-02-07 23:58:46 +01:00
ALTER TABLE phabricator_search.search_query
DROP authorPHID;
ALTER TABLE phabricator_search.search_query
ADD queryKey VARCHAR(12) NOT NULL;
/* Preserve URIs for old queries in case anyone has them bookmarked. */
UPDATE phabricator_search.search_query
SET queryKey = id;
ALTER TABLE phabricator_search.search_query
ADD UNIQUE KEY (queryKey);
Copy permalink