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.
Use profile URL (not URI), like elsewhere.
Profile::getUri() doesn't actually do anything useful, here--
it does nothing unless a plugin (like OStatus) is already
able to resolve the Profile into a backend object (e.g.: an Ostatus_profile).
If we might not already have an Ostatus_profile for a given Profile,
then we need to use $profile->getUrl() and fetch the data from that URL.
If we know the URI sent from the remote party, and we don't know the
notice it is replying to, we might still be able to put it in the same
conversation thread!
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.
Make the logic match the intent described in the comments.
The intent is clearly "accept notices whenever (A or B or C)", but
the logic implemented was more like "not ((not A) or (not B) or (not C))",
which is a basical boolean algebra fail (each of those ORs need to
become ANDs for double-negation to work).
The practical implication was that, for example, writing a reply
to someone else's notice and including an @-reference to _another_
user on another site to bring them into the discussion would
fail to deliver the notice to the new user because their server
would basically say `oh no, you can't message this user
from someone else's thread' because an earlier check for
the `A' or `C' parts of `(A or B or C)' prevents `B' from
being checked.
cf.: <http://status.hackerposse.com/notice/55846>, which was
refused by the nhcrossing.com server because it didn't know
about <http://sn.jonkman.ca/notice/93724>, even though it would
have passed the later `notice contains a reference to a local user'
check if not for an exception being prematurely thrown.
The whole idea of reporting `which specific check FAILED'
in an `if ANY SUCCEEDS' analysis is just bogus, so nix all of
the distinct ClientExceptions--a single `ALL FAILED' exception
is the only one that makes sense.
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
This is more of a proof of concept and will likely not stay in exactly
this form. We should reasonably deliver the entire notice upon webfinger
querying.
Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
"[...] 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.
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
We're also now using $config['image']['jpegquality'] to determine the
quality setting for resized images.
To set Avatar max size, adjust $config['avatar']['maxsize']
The getAvatar call now throws exceptions too. Related changes applied.
Now let's move Profile->avatarUrl to the Avatar class!
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
Orbited plugin may not work at all anymore, I had no means to try it.
But there's a check whether 'LACONICA' is defined there, which is a
very unlikely thing in the future. So far only tests and scripts have
been migrated consistently, though.
I had a problem with PHP5.5 that caused ajax responses to be empty. This
fixes it, as the problem was related to pretty inconsistent calling to
headers, XMLWriter::startDocument etc. etc.
getUser calls are much more strict, and one place where this was found was
in the (un)subscribe start/end event handlers, which resulted in making the
Subscription class a bit stricter, regarding ::start and ::cancel at least.
Several minor fixes in many files were made due to this.
This does NOT touch the Foreign_link function, which should also have a more
strict getUser call. That is a future project.
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).
