Brion Vibber [Fri, 29 Oct 2010 01:26:48 +0000 (18:26 -0700)]
Work in progress: starting on new TwitterDaemon using the Site Streams API -- code is incomplete, pulling bits from streamtest.php pending a chance to test the actual site-streams mode
Brion Vibber [Thu, 28 Oct 2010 19:58:30 +0000 (12:58 -0700)]
Kill a ping queue item if we get an error on loading up the notice's poster's profile, rather than letting the item be retried over and over as if it were a transitory error.
This shouldn't generally happen as it's an indicator of database inconsistency, but it's a condition we know happens.
Fields:
* action: case-normalized name of the action class we're acting on
* method: GET, POST, HEAD, etc
* ssl: Are we on HTTPS? 'yes' or 'no'
* query: Were we sent a query string? 'yes', 'no', or 'since_id' if the only parameter is a since_id
* cookie: Were we sent any cookies? 'yes' or 'no'
* auth: Were we sent an HTTP Authorization header? 'yes' or 'no'
* ifmatch: Were we sent an HTTP If-Match header for an ETag? 'yes' or 'no'
* ifmod: Were we sent an HTTP If-Modified-Since header? 'yes' or 'no'
* agent: User-agent string, to aid in figuring out what these things are
The most shared-cache-friendly requests will be non-SSL GET requests with no or very predictable
query parameters, no cookies, and no authorization headers. Private caching (eg within a supporting
user-agent) could still be friendly to SSL and auth'd GET requests.
We kind of expect that the most frequent hits from clients will be GETs for a few common timelines,
with auth headers, a since_id-only query, and no cookies. These should at least be amenable to
returning 304 matches for etags or last-modified headers with private caching, but it's very
possible that most clients won't actually think to save and send them. That would leave us expecting
to handle a lot of timeline since_id hits that return a valid API response with no notices.
At this point we don't expect to actually see if-match or if-modified-since a lot since most of our
API responses are marked as uncacheable; so even if we output them they're not getting sent back to
us.
Random subsampling can be enabled by setting the 'frequency' parameter smaller than 1.0:
addPlugin('ApiLogger', array(
'frequency' => 0.5 // Record 50% of API hits
));
Brion Vibber [Fri, 22 Oct 2010 20:53:10 +0000 (13:53 -0700)]
Additional fixes found while looking at ticket #2532: when given a screen name as API parameter for a profile, do the nickname lookup on local users only. The profile table can't guarantee unique lookups, so using names isn't currently safe there. This won't affect anything using local nicknames correctly, and may avoid some weird bugs if there were conflicts between local and remote nicknames.
Brion Vibber [Fri, 22 Oct 2010 20:51:28 +0000 (13:51 -0700)]
Fix for ticket #2532: fixed API block create/destroy when specifying the target user/profile as a separate query parameter, such as api/blocks/create.xml?param=xxx
The router settings weren't quite right so we ended up with bogus regex values passed in as the 'id' parameter, which broke the regular fallback ordering of parameter checks.
Brion Vibber [Fri, 22 Oct 2010 19:10:11 +0000 (12:10 -0700)]
Fix for 140-char replies being unexpectedly cropped when bridged to Twitter.
This drops the '@' -> ' @' hack for CURL meta-chars in outgoing Twitter bridge, added in commit 04b95c25 back in the day.
The Twitter bridge has since been switched from using direct CURL calls to using HTTPClient, which even with the CURL backend enabled doesn't trigger this issue, as POST parameters are formatted directly.
Prepending the space before we did the message cropping was leading to 140-char messages getting cropped unnecessarily, which was confusing:
Examples of broken messages:
http://identi.ca/notice/57172587 vs http://twitter.com/marjoleink/status/28398050691
http://identi.ca/notice/57172878 vs http://twitter.com/marjoleink/status/28398492563
Brion Vibber [Fri, 22 Oct 2010 18:07:19 +0000 (11:07 -0700)]
RegisterThrottlePlugin tweak for silencing checks: make sure we don't crash during registration if another profile registered from this address has been since deleted.
Zach Copley [Thu, 21 Oct 2010 19:23:04 +0000 (12:23 -0700)]
New "desktop" mode for the OAuth authorization page. If mode=deskstop
is specified in the request the page is probably meant to be displayed
in a small webview of another application, so suppress header, aside
and footer.
Brion Vibber [Wed, 20 Oct 2010 23:14:32 +0000 (16:14 -0700)]
Pretty up the OpenID variant of the OAuth login form a bit; change the 'Allow' button to 'Continue' so we're not confused why we get the form again after authenticating.
* translator documentation added.
* moved some translator comments that were not directly above the line with the message to the correct location.
* i18n for UI text.
* superfluous whitespace removed.
Brion Vibber [Wed, 20 Oct 2010 21:34:25 +0000 (14:34 -0700)]
Fix for ticket #2845: singleuser nickname configuration was being overridden by site owner in router setup.
I've consolidated the checks for which user to use for single-user mode into User::singleUser(), which now uses the configured nickname by preference, falling back to the site owner if it's unset.
This is now called consistently from the places that needed to use the primary user's nickname in routing setup.
Setting $config['singleuser']['nickname'] should now work again as expected.
Zach Copley [Wed, 20 Oct 2010 18:41:04 +0000 (11:41 -0700)]
Revert DB change for OAuth. Change compound key for oauth_application_user
back to (profile_id, application_id). I think we can get away without
a DB change by only issuing one anonymous access token per user.
projects / quix0rs-gnu-social.git / log