User::getTaggedSubscriptions()
This change escapes the $tag argument to prevent a SQL injection
attack in User::getTaggedSubscriptions(). The parameter was not
escaped higher up the stack, so this vulnerability could be exploited.
This change escapes the argument to User::getTaggedSubscribers() to
prevent SQL injection attacks.
Both code paths up the stack fail to escape this parameter, so this is
a potential SQL injection attack.
This patch escapes query parameters in Profile_tag::getTagged(). This
is an extra security step; since these parameters come out of the
database, it's unlikely that they would have dangerous data in them.
This change adds additional escapes for arguments to
Profile_tag::moveTag(). The arguments are canonicalized in the API and
Web UI paths higher up the stack, but this change makes sure that no
other paths can introduce SQL injection errors.
This patch escapes the $tag parameter in
Profile::getTaggedSubscribers(). The parameter is not escaped either
in actions/subscriptions.php or in actions/apiuserfollowers.php. So
there is a potential for SQL injection here.
This change escapes a parameter in Local_group::setNickname(). Review
of the code paths that call this function sanitize the parameter
higher up the stack, but it's escaped here to prevent mistakes later.
Note that nickname parameters are normally alphanum strings, so
there's not much danger in double-escaping them.
This change escapes a parameter in Local_group::setNickname(). Review
of the code paths that call this function sanitize the parameter
higher up the stack, but it's escaped here to prevent mistakes later.
Note that nickname parameters are normally alphanum strings, so
there's not much danger in double-escaping them.
commit 74c5e4cce42ae601c07b447e100f097c15ebf9d2
Author: Evan Prodromou <evan@status.net>
Date: Thu Oct 20 12:48:52 2011 -0400
Add back in some optimization indices lost in schema conversion
commit ef5c2acfcd123b25910a1c8bb4ae01a3f9608e5e
Author: Evan Prodromou <evan@status.net>
Date: Thu Oct 20 12:29:57 2011 -0400
restore some of the lost optimized indices on notice table
commit fb1dfa9e98ded23fb5bdebae6465424a8cb8acd6
Author: Evan Prodromou <evan@status.net>
Date: Thu Oct 20 10:40:07 2011 -0400
Use popular notice stream for favorited page
commit e1d409ff738e39061ad35589d546ce9bed456975
Author: Evan Prodromou <evan@status.net>
Date: Thu Oct 20 10:32:23 2011 -0400
Use a caching stream for popular notice section
Instead of a big cached query, we now use a caching notice stream for
the popular notice section. It uses a single-table query at the
bottom, then scopes the notices and filters for silenced users. This
should be much nicer to our database servers.
Also clears the popular cache when someone favors or disfavors
something. A nice optimization would be to save the last weights and
re-calculate them at invalidation time, adding the new notice (or not)
depending on its own score. That will have to wait for another day,
though.
commit e9b7ab4c26c95e755adaff53c3957dcfca31c16b
Author: Evan Prodromou <evan@status.net>
Date: Thu Oct 20 10:31:14 2011 -0400
Let CachingNoticeStream users skip the ';last' optimization
This should resolve the issues darkip was reporting with user_im_prefs entries returning null immediately after insertion (seen with memcached off, so it was happening even with the built-in in-process cache in the Cache base class).
What was happening was that the initial pkeyGet() would end up saving a negative cache entry under the form with the fields sorted in the key, as via multicacheKey():
'statusnet:blaguette:user_im_prefs:screenname,transport:brionv,sms' => 'N;'
then we'd do an insert() on the new entry, saving cache entries for the non-sorted key names returned by _allCacheKeys():
'statusnet:blaguette:user_im_prefs:transport,screenname:sms,brionv' => 'O...'
'statusnet:blaguette:user_im_prefs:user_id,transport:1234,sms' => 'O...'
but the next query via pkeyGet() still saw the negative lookup cache from before, and came back with null.
Now, _allCacheKeys() sorts the fields in the keys by using the same key-builder function, and queries pick up the same thing you just inserted. :)
Memcached_DataObject doesn't quite fully understand unique indexes, and can't properly build cache keys for compound unique or primary keys.
Managed_DataObject has more information in its schema data, so we can build a proper list.
* '1.0.x' of gitorious.org:statusnet/mainline:
Issue #546: enable case-insensitive searching in MySQL
remove more groupnav
remove group nav
shorter title for tag cloud section on groups
remove group nav
move pending queue to sidebar
Move group logo edit from object nav to block actions
Show blocked users from group in section
MySQL needs the collation utf8_general_ci to support case-insensitive
searching. lib/mysqlschema.php already supports a 'collate' attribute on
a per-column basis, so we just need to take advantage of that attribute
on the columns we want to search and Bob (and BOB, and bOB) is your
uncle.
Signed-off-by: Dan Scott <dan@coffeecode.net>
I was storing the full objects in the cache for the listGet()
function. I've changed it to store only pkeys, and use pivotGet() to
get all the corresponding values.
This also required changing pivotGet() so it can get objects with
multi-column pkeys, which complicated the whole thing quite a bit. But
it seems to work OK.
This method lets you get all the objects with a given variable key and
another set of "fixed" keys. A good example is getting all the avatars
for a notice list; the avatar size stays the same, but the IDs change.
Since it's very similar to multiGet(), I refactored that function to
use pivotGet().
And, yes, I realize these are kind of hard to follow.
