The related issue passes the username, email, and ip to the service as an array. This causes the service to return the results also as an array. But none of the callers to spambot_sfs_request() expect the $data set by reference to be an indexed array of results.
Try to validate an account and notice that the result is always a "pass", even if the service returned that the data from the account "appears" on the service.
Three options:
1. Change all the callers to spambot_sfs_request() to check for the result in array index 0
2. Revert the related issue and fix the caching elsewhere.
3. Write a helper that returns the results not in an indexed array.
Since eventually it would be useful to pass more than one item to the service, as is allowed, I favor option 3.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | spambot-service_query_cache-14077470-3.patch | 6.6 KB | danchadwick |
Comments
Comment #2
danchadwick commentedComment #3
danchadwick commentedI found and fixed tons of bugs -- wrong cache keys, wrong data being accessed, incorrect operation when some data but not all requested parameters are cache hits, plus every request was not working (because the resulting $data was contained an indexed array of results, rather than a single result).
This patch implements a service query on multiple username, email, and ip data. The cache is checked for each before query and are not queried if returned in the cache. The results from the request, if any, are then cached. So a request can result in a full miss, a full hit, or a mixture of the two.
Comment #4
kala4ekComment #6
kala4ek