Самым близким к стандартному способу обработки этого, о котором я знаю, является использование <link> с rel="me".Google Buzz использует этот подход.По сути, у вас есть что-то подобное в ленте:
<link rel="me" type="text/html" href="http://www.google.com/profiles/username"/>
Это означает, что фид принадлежит тому же человеку, что и http://www.google.com/profiles/username.Вы можете иметь несколько элементов link с одним и тем же rel, поэтому у вас могут быть ссылки на несколько пользовательских профилей (обычно это профили одного и того же человека в нескольких службах) в одном фиде.
Альтернативный подходпотребовать, чтобы пользователь поместил случайный магический токен в тело своего канала.Этот токен должен существовать только для одной выборки, поэтому пользователь может удалить его, как только ваш сервис определит, что он владеет фидом.Я думаю, что этот подход, возможно, использовался Feedburner.Проблема этого подхода заключается в том, что он открыт для злоупотреблений фидами совокупного пользовательского контента.Например, злонамеренный пользователь может довольно легко заявить, что у него есть лента комментариев или лента изменений в вики.Требование, чтобы магический токен был в описании канала, а не в элементе, может быть способом решения этой проблемы, хотя это может создать проблемы для пользователей, которые не имеют низкоуровневого контроля над своим каналом.(например, пользователи определенных систем управления контентом или инструментов для ведения блогов). Подход rel=me также имеет эту проблему, но, по крайней мере, он стандартен, так что, надеюсь, создатели упомянутых инструментов CMS / ведения блогов могут быть убеждены в добавлении поддержки rel=me.
Третий подход состоит в том, чтобы потребовать от пользователя подтверждения того, что он владеет доменом, как вы упомянули.Это имеет некоторые проблемы, так как пользователь может владеть только деревом каталогов в домене или поддомене.Вы не хотите брать на себя ответственность за весь домен только потому, что пользователь может редактировать файл в некотором подкаталоге или поддомене.«Каталог» и хост «проверочного» URL-адреса, вероятно, должны быть предком URL-адреса канала.Например, если я могу контролировать example.com/foo/proof.txt, это не значит, что я владею example.com/quux/zarf.xml.Если я могу контролировать example.com/quux/proof.txt или example.com/proof.txt, то это, вероятно, достаточно хорошо.