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.
The 'created' column in ostatus_source SQL table has NOT NULL restriction.
INSERTs fail when running MySQL/MariaDB in strict mode if this is not
populated.
This fixes an issue where INSERTs in HubSub fail if MySQL/MariaDB is
running in "strict mode" since the default lease time in
PushHubAction::subunsub is null.
Permanent subscriptions have been removed in PuSH v0.4, but they are
being kept here for backward-compatibility with previous GS/SN versions.
If you accidentally deleted a remote user's avatar from filesystem,
it'd take until its URL was updated that you got it back. Now it
happens if the local avatar file doesn't exist.
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.
