After doublechecking two identities so that they match (like one that was
previously http:// but now is https://) we update the URI in our database
to match.
This has to be verified so it's not easy to fool our script and thus make
us replace legitimate URIs with fake ones. I believe the callback method
is safe, but I'm not sure how well it handles HTTP MITM attacks etc.
will verify unknown aliases against old ones if the new identifies as a
previously recognized URI.
Steps:
1. Check the newly received URI. Who does it say it is?
2. Compare these alleged identities to our local database.
3. If we found any locally stored identities, ask it about its aliases.
4. Do any of the aliases from our known identity match the recently introduced one?
Currently we do _not_ update the ostatus_profile table with the new URI.
This also fixes a problem with "initial salmon slap", which was a
problem for newly registered accounts which would have their first
salmon slap fail to distribute since there was a problem with Magicsig
keys. Apparently we have to re-read them with importKeys so the
Crypt_RSA objects publicKey and privateKey match later instances of them.
I think it may have been that generate() doesn't specify a signatureMode,
but I leave experimentation of that to the future.
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
XML_XRD::getAll requires arguments (at least relation). If one really
want all links, just get the 'links' array. It's public!
Also, not all XML_XRD_Element_Link were migrated from the previous
array style.
New plugins:
* LRDD
LRDD implements client-side RFC6415 and RFC7033 resource descriptor
discovery procedures. I.e. LRDD, host-meta and WebFinger stuff.
OStatus and OpenID now depend on the LRDD plugin (XML_XRD).
* WebFinger
This plugin implements the server-side of RFC6415 and RFC7033. Note:
WebFinger technically doesn't handle XRD, but we serve both that and
JRD (JSON Resource Descriptor), depending on Accept header and one
ugly hack to check for old StatusNet installations.
WebFinger depends on LRDD.
We might make this even prettier by using Net_WebFinger, but it is not
currently RFC7033 compliant (no /.well-known/webfinger resource GETs).
Disabling the WebFinger plugin would effectively render your site non-
federated (which might be desired on a private site).
Disabling the LRDD plugin would make your site unable to do modern web
URI lookups (making life just a little bit harder).
Allow the OStatus queue-handler to handle all posts,
and give it the smarts required to make correct decisions
about whether it should or shouldn't relay notices
over OStatus.
cf. http://status.net/open-source/issues/3540
Conflicts (staticGet => getKV):
plugins/OStatus/lib/ostatusqueuehandler.php
lib/plugin.php now has a parent onAutoload function that finds most common
files that are used in plugins (actions, dataobjects, forms, libs etc.) if
they are put in the standardised directories ('actions', 'classes', 'forms',
'lib' and perhaps some others in the future).
In commit e95f77d34c HubSub lost the
'staticGet' function in a consolidation into the Managed_DataObject class.
This was done carelessly by me as HubSub::staticGet was actually taking
two arguments, none of which was a key and merging them in HubSub::hashkey()
(staticGet was renamed getKV 2a4dc77a63).
NOTE: This complements commit 7e4718a4eb which
fixed a similar issue for the Magicsig class.
I used this hacky sed-command (run it from your GNU Social root, or change the first grep's path to where it actually lies) to do a rough fix on all ::staticGet calls and rename them to ::getKV
sed -i -s -e '/DataObject::staticGet/I!s/::staticGet/::getKV/Ig' $(grep -R ::staticGet `pwd`/* | grep -v -e '^extlib' | grep -v DataObject:: |grep -v "function staticGet"|cut -d: -f1 |sort |uniq)
If you're applying this, remember to change the Managed_DataObject and Memcached_DataObject function definitions of staticGet to getKV!
This might of course take some getting used to, or modification fo StatusNet plugins, but the result is that all the static calls (to staticGet) are now properly made without breaking PHP Strict Standards. Standards are there to be followed (and they caused some very bad confusion when used with get_called_class)
Reasonably any plugin or code that tests for the definition of 'GNUSOCIAL' or similar will take this change into consideration.
If set up, this hub will be used to subscribe to feeds that don't specify a hub of their own.
Assumes that the fallback hub will, in fact, handle polling and updates for any feed we throw at it!
Authentication may be specified for the fallback hub.
Example:
$config['feedsub']['fallback_hub'] = 'https://superfeedr.com/hubbub';
$config['feedsub']['hub_user'] = 'abcd';
$config['feedsub']['hub_pass'] = 'ckcmdkmckdmkcdk';
Also:
* Fix for WordPress-RSS-via-Superfeedr-Atom; if we have <author> info but no ID from a native ActivityStreams actor, don't freak out in the low-level processing code that checks for identity matches.
* enhanced messages for low-level FeedSub exceptions if they make it to outside display
The code pattern 'new XXXException($e)' to chain exceptions doesn't actually work as intended, as exceptions are actually expecting a string message here.
This caused an implicit string conversion from HTTP_Request2_Exception, which is a PEAR_Exception, which defines an absurdly detailed __toString() method including a giant HTML table with a backtrace if you happen to be on a web request.
Simply passing $e->getMessage() instead clears this up, as we'll get the nice short message like 'Couldn't connect to tcp://blahblah:80'
Parsing hcards for the data we need wasn't hard enough to justify using
hkit. It was dependent on a number of external systems (something to
run tidy), and only could handle XHTML.
We now parse HTML with the PHP dom libraries used elsewhere, and
scrape out our own hcards. Seems to work nicer and faster and most of
all works with Google Buzz profile URLs.
