Кто к нам с чем зачем, тот от того и того!
Вопрос на засыпку =)
Есть ли возможность при сегодняшнем состоянии дайри сделать RSS для избранного (оно же -- френдлента, .../?favorite)?
Мне кажется, что это будет вполне удобно и юзабельно.
ЗЫ кто-нибудь ещё считает идею стОящей? ^_^
УПД администраторы, отреагируйте как-нибудь...
Неужели неинтересное предложение?
Есть ли возможность при сегодняшнем состоянии дайри сделать RSS для избранного (оно же -- френдлента, .../?favorite)?
Мне кажется, что это будет вполне удобно и юзабельно.
ЗЫ кто-нибудь ещё считает идею стОящей? ^_^
УПД администраторы, отреагируйте как-нибудь...
Неужели неинтересное предложение?
Space.Cat, ваша любимая техподдержка и так открыта, а больше вас здесь ничего и не интересует, как я понял )
1. Лента содержит только полностью открытые записи; чуть выше я примел пример такой ленты — она малоинтересна.
2. Для импорта в другом блоге создается
pay.diary.ru/userdir/1/0/9/1/10912/4cd619ce3f4f... —
с уникальным адресом, не зависящим от ID и других данных пользователя. В ней могут быть все записи избранного, включая закрытые.
3. Можно сделать доступ с авторизацией
pay.diary.ru/~shortname/?rss&shortname=[shortname]&password=[$password] —
при этом будет проверяться авторизация и будут показываться записи как в дневнике, в том числе с заглушками "закрытая запись". Вместо логина и пароля можно использовать уникальный идентификатор, который пользователь получает в своих настройках, либо на почту или по SMS.
1 и 2 варианты создают нагрузку на сервер только в момент создания и для нас предпочтительнее.
3 вариант создает нагрузку при каждом обращении, но он удобнее пользователям.
2 и 3 варианты существенно снижают уровень безопасности: если такая ссылка попадает в чужие руки, то посторонние могут читать по ней чужие закрытые записи всю жизнь или до тех пор, пока ссылку не сменят, а в 3 варианте с паролем — еще и войти залогиненным на сайт. Здесь важно понимать, что охранять ссылку на свою ленту избранного будет не тот, кто писал закрытые записи, а другой — которому позволено их читать.
Ради чего надо подвергать такой опасности закрытые дневники и записи?
для безопасности и дневниковые РСС нужно убить =)нос, а чем плох вариант передачи вместо закрытых записей информации вида: «Закрытая запись. http:\\бла-бла-бла», без самого содержания? Зато пользователь ставится в известность о появлении поста (что немаловажно) и имеет возможность перейти к нему по ссылке (в случае, если он уже залогинен) или залогиниться на дайри и после этого воспользоваться адресом. =)
Да, в принципе, и первый вариант имеет право на существование (обычно так и делают).
Преимущество варианта 1 в том, что он работает без нагрузки на php и sql. В принципе, из этих файлов можно собрать избранное, но оно будет состоять только из открытых записей полностью открытых дневников.
Уже частично реализован сбор избранного из этих открытых rss + к нему, думаю, стоит добавить заглушки про закрытые записи, чтобы пользователь, у которого есть доступ знал о том, что эти записи есть и мог пойти на сайт и посмотреть.
И еще. Вариант 2 — это для тех кто хочет сделать автоматическую трансляцию своих записей на другой сайт, а не для избранного, и, естественно, авторизация через куки здесь не пройдет, т.к. эти куки установлены у вас на компьютере, а тот сервер, который будет запрашивать вашу rss, про них ничего не знает.
Тем, что авторизационные данные не передаются в ссылке, которая может быть перехвачена в десятке мест (логи прокси, закладки/история агрегатора и т.п.). В предложенном варианте уровень безопасности не снижается и соответствует стандартному для дневников.
Вариант 2 — это для тех кто хочет сделать автоматическую трансляцию своих записей на другой сайт, а не для избранного, и, естественно, авторизация через куки здесь не пройдет, т.к. эти куки установлены у вас на компьютере, а тот сервер, который будет запрашивать вашу rss, про них ничего не знает.
Одна дополнительная строчка в http-запросе скрипта, забирающего фид (сoоkiе: user_login=логин; user_pass=мд5хэш_пароля) позволит работать с дневниками как залогиненный пользователь. Так у меня работают два робота, вап-сервис и скриптик always online.
Существующая альтернатива первому варианту - собрать интересующие фиды в, например, яндекс.ленту, или просто добавить все нужное в агрегатор.
gluker, ммм, идеальный вариант =)
Существующая альтернатива первому варианту - собрать интересующие фиды в, например, яндекс.ленту, или просто добавить все нужное в агрегатор. - думаю тут речь о том, что можно вручную собрать интересующие rss, созданные по варианту 1 в одном месте? Пожалуйста, никто не запрещает, это и сейчас можно сделать. Речь ведь шла о том чтобы собирать их у нас на сайте, не беспокоясь о том что если я кого-то добавил или удалил в избранном, то мне нужно и еще где-то соответствующий rss добавить или удалить, а заглушки на закрытые записи ставить нужно для того чтобы у того, кто смотрит ленту не на сайте, а через rss, не было необходимости идти смотреть еще и на сайт — есть ли закрытые записи? Это, конечно, снижает нам посещаемость, что с одной стороны плохо, но делает конечному юзеру пользование избранным более удобным.
Не согласен. Между передачей авторизации в параметрах ссылки и в куках - большая разница, т.к. куки доступны только у конечного пользователя, и то не каждому встречному, ссылка же с аутентификационными данными, по которой он перешел, "светится" по всему маршруту и попадает в хистори, которая не удаляется кнопочкой "выход", в отличие от куков. Я, прежде всего, имел ввиду возможность не трансляции ленты избранного на сторонний сайт, а чтение ее через персональный рсс-агрегатор - что было бы максимально удобно многим пользователям. Безопасность данных (равно как и нагрузка на сервер) в случае получения рсс с авторизацией по кукам абсолютно идентична просмотру избранного залогиненным пользователем, т.к. меняется только форма выдачи данных: вместо html-страницы отдается xml-фид.
Кстати, ничего не мешает, например, обращаться к скрипту на сторонний сайт, отдавая ему валидные куки, по переданной авторизации скрипт будет забирать нужное избранное с дневников и переделывать его в xml - получится аналог 4 варианта с соблюдением всех приватностей. Почему нельзя сделать это намного проще средствами самих дневников?
Описанный мной вариант является аналогом обычного избранного, только вместо html клиент получает rss. Приватность и нагрузка на сервер в обоих вариантах идентичны, во втором случае даже снижается трафик - из-за отсутствия ненужных для чтения html-элементов и возможности отдать клиенту 304 not modifed при отсутствии новой информации.
Cейчас лента избранного — это одна из самых тяжелых функций для серверов, а вы предлагаете сделать так, чтобы ее могли запускать еще и не заходя на сайт...
«т.к. куки доступны только у конечного пользователя, и то не каждому встречному, ссылка же с аутентификационными данными, по которой он перешел, "светится" по всему маршруту » — каким же образом куки попадают на сервер если не идут тем же маршрутом?
«Кстати, ничего не мешает, например, обращаться к скрипту на сторонний сайт, отдавая ему валидные куки, по переданной авторизации скрипт» — может нам еще и со сторонними сайтами договариваться, чтобы они в настройках импорта rss, кроме адреса, запрашивали еще и куки?
Повторю еще раз: rss сейчас — статичные файлы, обращение к которым не создает нагрузку на сервер, тут нужно найти компромисс, сделав так, что пользователям не нужно будет приходить к нам на сайт, но при этом они будут напрягать сервера, мы конечно же сделаем им хорошо; оставив RSS как сейчас, мы сделаем хорошо серверам, но пользователям будет не так удобно как хотелось бы. Так вот, компромиссом является модернизированный вариант 1.
Маршрут тот же. Уровень приватности разного порядка. Адрес ссылки с авторизацией остается в хистори/закладках, т.е., уже заведомо доступен широкому кругу лиц; куки уничтожаются кнопочкой "выход" на сайте. Перейдя на какой-нибудь сайт из рсс-ленты, мы можем подарить авторизационные данные в виде реферера. В любом случае, метод передачи логина/пароля по ссылке является менее надежным.
может нам еще и со сторонними сайтами договариваться чтобы они в настройках импорта rss кроме адреса запрашивали еще и куки?
Нет, имел ввиду, что при желании таким образом легко могу сделать рсс-ленту избранного для себя и/или знакомых))
В общем, причина не в нежелании/неумении, а в преусловутой нагрузке на сервер и снижении посещаемости. Вопросов больше не имею))
«В общем, причина не в нежелании/неумении, а в преусловутой нагрузке на сервер и снижении посещаемости. Вопросов больше не имею)) » - так про три варианта написали так в принципе, объяснив то что они есть и мы в курсе что они есть, про то что можно авторизоваться через куки мы тоже где-то слышали
с развитием системы, когда нагрузка будет менее критичным показателем, возможно механизм изменится, но это будет не так скоро, а потому пока о том и нет разговора...
Space.Cat, «DDD плюс адын, фу... ((((( » - это вы кому фу?
DDD, сейчас rss обновляется конечно же при создании записи, зачем создавать по запросу если сейчас там хранится только открытая для всех информация, да и по расписанию создавать - нехорошо т.к. после появления записи она должна сразу появляться и в rss, да и выборку лишний раз не нужно делать т.е. вся информация для обновления рсс уже есть
1) не очень большое количесвто людей поймут как это использовать \ ненайдут сайт
2) не обязательно делать это на автомате, а например только при обращении к одминистратору
Жаль, что 4 вариант сейчас нереализуем. Имхо, он наиболее перспективен из всех предложенных, особенно если сосуществовать его с 1 вариантом для универсальности.
Будем ждать. Функционал этот, что ни говори, востребованный.
gluker не думаю что люди часто пользуются браузером для просмотра rss
К сожалению сейчас ссылку не найду, но читал (на википедии вроде бы, но не уверен) что более 70% читающих рсс-ленты пользуются именно браузером для их просмотра. Особенно если браузер - Опера.
Которая умеет авторизованно запрашивать рсс