Commit graph

14 commits

Author SHA1 Message Date
S.H
2b9de88f26 Update Rails (#8141)
* Update Rails

* fix Update Rails
2018-08-13 18:17:20 +02:00
Yamagishi Kazutoshi
7da649efb4 Use raw status code on have_http_status (#7214) 2018-04-21 21:35:07 +02:00
Eugen Rochko
3473aac8d8 Hook up URL-based resource look-up to ActivityPub (#4589) 2017-08-14 02:29:36 +02:00
Matt Jankowski
5a54a5ba69 Clean up api/subscriptions controller (#3448) 2017-05-31 02:15:09 +02:00
Eugen Rochko
91a8a5eab8 Fix #2706 - Always respond with 200 to PuSH payloads (#2733)
Fix #2196 - Respond with 201 when Salmon accepted, 400 when unverified
Fix #2629 - Correctly handle confirm_domain? for local accounts
Unify rules for extracting author acct from XML, prefer <email>, fall back
to <name> + <uri> (see also #2017, #2172)
2017-05-03 17:02:18 +02:00
Eugen Rochko
23162b2893 Update hub URL and re-subscribe if hub URL changes 2016-11-26 15:18:21 +01:00
Eugen Rochko
c6b0311b86 Fix #54 - Fetch remote accounts by URL from mentions
Fetching atom extracted from FetchRemoteAccountService and FetchRemoteStatusService
into FetchAtomService. Mentions of the constant "http://activityschema.org/collection/public"
skipped as it's not a real URL/user.
2016-09-26 16:44:40 +02:00
Eugen Rochko
4bec613897 Fix #24 - Thread resolving for remote statuses
This is a big one, so let me enumerate:

Accounts as well as stream entry pages now contain Link headers that
reference the Atom feed and Webfinger URL for the former and Atom entry
for the latter. So you only need to HEAD those resources to get that
information, no need to download and parse HTML <link>s.

ProcessFeedService will now queue ThreadResolveWorker for each remote
status that it cannot find otherwise. Furthermore, entries are now
processed in reverse order (from bottom to top) in case a newer entry
references a chronologically previous one.

ThreadResolveWorker uses FetchRemoteStatusService to obtain a status
and attach the child status it was queued for to it.

FetchRemoteStatusService looks up the URL, first with a HEAD, tests
if it's an Atom feed, in which case it processes it directly. Next
for Link headers to the Atom feed, in which case that is fetched
and processed. Lastly if it's HTML, it is checked for <link>s to the Atom
feed, and if such is found, that is fetched and processed. The account for
the status is derived from author/name attribute in the XML and the hostname
in the URL (domain). FollowRemoteAccountService and ProcessFeedService
are used.

This means that potentially threads are resolved recursively until a dead-end
is encountered, however it is performed asynchronously over background jobs,
so it should be ok.
2016-09-21 01:50:31 +02:00
Eugen Rochko
608a2bfffc Upgrade to PubSubHubbub 0.4 (removing verify_token) 2016-09-20 02:43:20 +02:00
Eugen Rochko
87576e1ab1 Fixing atom feeds for accounts, adding tests that would catch such bugs in future 2016-09-08 00:33:07 +02:00
Eugen Rochko
10ba09f546 Upgrade to Rails 5.0.0.1 2016-08-17 17:58:00 +02:00
Eugen Rochko
35aafdba96 Ancestors and descendants of statuses 2016-03-21 11:43:21 +01:00
Eugen Rochko
b640f35621 Writing out more tests, fixed some bugs 2016-03-20 13:03:06 +01:00
Eugen Rochko
0e8f59c16f Refactoring Grape API methods into normal controllers & other things 2016-02-29 19:42:08 +01:00