At the same time we change this to call ActivityUtils::checkAuthorship
instead to let the retrieval/verification go through event handling.
rozzin (Joshua Judson Rosen) found this error. Thanks.
We need to look up a feed profile for HandleFeedEntryWithProfile events,
regardless of whether they're an OStatus user, group, or something else;
this is the least hairy way of doing that--the alternative being
to keep spreading the same logic all over the calling code.
Theoretically, this change might allow OStatusGroups to be recorded
as the authors of activities if they pass through any authorless
activities; but that's why we have checkAuthorship().
Similarly to what ActivityUtils::checkAuthorship does; try to ensure
that activities from ambiguous OStatus feeds (groups and peopletags)
that require explicit authorship don't get in without explicit authors.
Lost dependency of OStatus plugin for lib/microappplugin.php, whoo!
also noting which plugins should be upgraded to new saveActivity support.
Favorite plugin won't work with the new system just yet, it doesn't have
the necessary functions to extract activity objects, but that's coming
in the next (few) commits.
saveActivity will accept an Activity which gets parsed and saved through
plugins. So when an ActivityHandlerPlugin (such as Favorite will be soon)
gets a feed to save, this will be the function called instead of saveNew.
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.
There was a problem with (specifically at least) PuSHpress for
Wordpress. A previous attempt to perform a DB transaction backfired
because the remote side could connect to the callback before our
commit had gone through.
I take full responsibility for introducing the bug in the first place :)
Among other things (such as permanent subscriptions), Pubsubhubbub 0.4
removed the "sync" verification method. This means that any incoming
PuSH subscription requests that follow the 0.4 spec won't really
_require_that we handle it as a background process, but if we were to
try direct verification of the subscription - and fail - there's no way
we could pick up the ball again. So _essentially_ we require background
processing with retries.
This means we must implement something like the "poorman cron" or
similar, so background processing can be handled
on-demand/on-site-visit. This is how Friendica, Drupal etc. handles it
and is necessary for environments where we can't run separate queue
daemons.
When the poorman-cron-ish thing is implemented, auto-renewal will work
for all users.
PuSH 0.4 spec:
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
More on PuSH 0.4 release (incl. breaking changes):
https://groups.google.com/forum/#!msg/pubsubhubbub/7RPlYMds4RI/2mIHQTdV3aoJ
"[...] posts _local_ users (like you) make won't get data about "repeated by"
from federated users"
This was because the ActivityObject would processShare where the shared object
has a _local_ 'actor' URI. Ostatus_profile would complain this meant that a
"Local user cannot be referenced as remote.".
So we see if the shared activity object's id (URI) is in our Notice table, so
we don't have to processActivity - and can skip ensureActivityObjectProfile.
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).
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.
In commit e95f77d34c Magicsig lost the 'staticGet' function (later renamed to getKV in 2a4dc77a63 ), which was important to properly initialize the Magicsig object (fromString)
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.
In some brief tests, this causes no problems.
In this state however, you would need to modify DB_DataObject to have a static declaration of staticget (and probably pkeyGet). The next commit will change the staticGet overload to a unique function name (like getKV for getKeyValue), which means we can properly call the function by PHP Strict Standards.
The switch to having a function in Managed_DataObject is now being applied
to plugins which can use this as well.
There are some plugins that still use Memcached_DataObject, but these will
be taken care of later.
Output from 0.9.6 PuSH feeds seems to have a rump <author> but no
<activity:actor>. It was overwriting valid and useful data set up at
subscribe time.
This fix tries to avoid overwriting data. However, it may prevent
updates that delete data.
Bug: 3028
StatusNet core code now sets the tooltip text on .attachment.more links when they receive their attachment-expansion magic; this will override the hardcoded tooltip text saved from OStatus plugin when displaying timelines in the web UI.
Changes in 2d4e0693c8 changed Ostatus_profile::filterReplies() (which sorts out the local, remote, and group recipients on incoming remote messages) from checking for remote profiles with a safe call to Ostatus_profile::staticGet() to calls through Ostatus_profile::ensureProfileURL() and Ostatus_profile::ensureWebfinger(), which throw exceptions and thus abort processing.
Since this was done before checking for local groups, the filter would fail when the ensure* functions determined it was looking at a local group and rightfully refused to create a remote group profile for it.
Changing the calls to the ensure* functions was done so we can record remote reply recipients for future reply-to-reply processing (the staticGet() call was a cheaper way to do a lookup when we knew we only actually had to process groups that somebody signed up to); most important fix is simply to actually check for the exception! :)
Here I'm changing the order of processing so we do the local group lookup first -- where it's nice and safe -- and then when we do the remote checks, we'll go ahead and gracefully skip that entry if the full remote lookup fails, so we'll still process any following recipients.
The original-size file is now forced to 0644 (all-readable), which should help. Not sure this is 100% ideal, but it's better than 0600!
(The other sizes were being created in other code and had sane read perms already.)
Watch out for similar issues in Twitter bridge etc; avatar import code should get cleaned up and consolidated.
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
SubMirror: redid add-mirror frontend to accept a feed URL, then pass that on to OStatus, instead of pulling from your subscriptions.
Profile: tweaked subscriberCount() so it doesn't subtract 1 for foreign profiles who aren't subscribed to themselves; instead excludes the self-subscription in the count query.
Memcached_DataObject: tweak to avoid extra error spew in the DB error raising
Work in progress: tweaking feedsub garbage collection so we can count other uses
The ensure* family of functions will now return an OStatusShadowException in this case, which gives us a pleasant error message instead of a giant exception backtrace when you do 'sub somebody@this.local.server'.
Can be extended later to allow actually using the local profile, since we could figure it out.
Conflicts:
lib/attachmentlist.php
plugins/OStatus/classes/Ostatus_profile.php
Merge tried to delete things that it seems it shouldn't, very confusing order. Hope rest of the cherry-picking isn't a problem.
* drop OStatusPlugin::localProfileFromUrl(), we can just look up on user.uri
* clean up a few edge cases that returned null through Ostatus_profile::ensure* code paths, now throws clear exception when we can't find a feed from the given profile url
* add some doc comments on the ensure* methods
