2016-11-16 00:56:29 +09:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2016-03-01 03:42:08 +09:00
|
|
|
class StreamEntriesController < ApplicationController
|
2017-05-30 01:22:22 +09:00
|
|
|
include Authorization
|
2017-07-15 03:41:49 +09:00
|
|
|
include SignatureVerification
|
2017-05-30 01:22:22 +09:00
|
|
|
|
2016-03-06 07:42:40 +09:00
|
|
|
layout 'public'
|
|
|
|
|
2016-03-01 03:42:08 +09:00
|
|
|
before_action :set_account
|
|
|
|
before_action :set_stream_entry
|
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 08:34:14 +09:00
|
|
|
before_action :set_link_headers
|
2016-12-07 02:03:30 +09:00
|
|
|
before_action :check_account_suspension
|
2016-03-01 03:42:08 +09:00
|
|
|
|
|
|
|
def show
|
|
|
|
respond_to do |format|
|
2016-10-05 20:26:44 +09:00
|
|
|
format.html do
|
2017-05-23 22:04:23 +09:00
|
|
|
@ancestors = @stream_entry.activity.reply? ? cache_collection(@stream_entry.activity.ancestors(current_account), Status) : []
|
|
|
|
@descendants = cache_collection(@stream_entry.activity.descendants(current_account), Status)
|
2016-10-05 20:26:44 +09:00
|
|
|
end
|
|
|
|
|
2017-04-07 12:56:56 +09:00
|
|
|
format.atom do
|
2017-07-19 08:37:26 +09:00
|
|
|
render xml: OStatus::AtomSerializer.render(OStatus::AtomSerializer.new.entry(@stream_entry, true))
|
2017-04-07 12:56:56 +09:00
|
|
|
end
|
2016-03-01 03:42:08 +09:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-12-18 23:20:39 +09:00
|
|
|
def embed
|
2017-08-30 17:23:43 +09:00
|
|
|
redirect_to embed_short_account_status_url(@account, @stream_entry.activity), status: 301
|
2016-12-18 23:20:39 +09:00
|
|
|
end
|
|
|
|
|
2016-03-01 03:42:08 +09:00
|
|
|
private
|
|
|
|
|
|
|
|
def set_account
|
2016-09-05 04:06:04 +09:00
|
|
|
@account = Account.find_local!(params[:account_username])
|
2016-03-01 03:42:08 +09:00
|
|
|
end
|
|
|
|
|
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 08:34:14 +09:00
|
|
|
def set_link_headers
|
2017-08-13 07:45:04 +09:00
|
|
|
response.headers['Link'] = LinkHeader.new(
|
|
|
|
[
|
|
|
|
[account_stream_entry_url(@account, @stream_entry, format: 'atom'), [%w(rel alternate), %w(type application/atom+xml)]],
|
|
|
|
[ActivityPub::TagManager.instance.uri_for(@stream_entry.activity), [%w(rel alternate), %w(type application/activity+json)]],
|
|
|
|
]
|
|
|
|
)
|
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 08:34:14 +09:00
|
|
|
end
|
|
|
|
|
2016-03-01 03:42:08 +09:00
|
|
|
def set_stream_entry
|
2017-02-17 10:20:52 +09:00
|
|
|
@stream_entry = @account.stream_entries.where(activity_type: 'Status').find(params[:id])
|
2016-12-19 03:47:11 +09:00
|
|
|
@type = @stream_entry.activity_type.downcase
|
2016-12-23 07:03:57 +09:00
|
|
|
|
2017-05-30 01:22:22 +09:00
|
|
|
raise ActiveRecord::RecordNotFound if @stream_entry.activity.nil?
|
2017-10-09 22:56:17 +09:00
|
|
|
authorize @stream_entry.activity, :show? if @stream_entry.hidden? || @stream_entry.local_only?
|
2017-05-30 01:22:22 +09:00
|
|
|
rescue Mastodon::NotPermittedError
|
|
|
|
# Reraise in order to get a 404
|
|
|
|
raise ActiveRecord::RecordNotFound
|
2016-03-01 03:42:08 +09:00
|
|
|
end
|
2016-12-07 02:03:30 +09:00
|
|
|
|
|
|
|
def check_account_suspension
|
2017-03-20 04:03:28 +09:00
|
|
|
gone if @account.suspended?
|
2016-12-07 02:03:30 +09:00
|
|
|
end
|
2016-03-01 03:42:08 +09:00
|
|
|
end
|