WackoWiki: НпЖ/РаботаПоCSA ...

To Do?

1. сделать хендлер auth узла
   1. ставит бесконечное печенье authto, если оно не стоит и есть $_GET["authto"]
   2. при неавторизованном пользователе и наличии $_REQUEST["authto"] должен запускать процесс авторизации (картинка и прочая)
   3. при наличии $_GET["for"] запускать процесс trackback
   4. при наличии $_GET["back"] запускать процесс приёма trackback-а
2. он вызывается в Npj RH?::_HandleRequest где-то
3. Нужна запись в users. Таким образом, трекбек передаёт около десятка параметров. Очевидно, он POST.
4. Вопросы.
   1. Как сделать после успешного трекбека юзера залогиненым? Смотри cheat.
   2. Либу для работы с HTTP возьмём какую-либо или будем наколенничать? Выбран HTTP_Client из PEAR.

ТЗ

1. В ситуациях (a) & (b) Нпж Адрес Узла? прописки? передаётся GET-параметром в ссылке ?authto=lrpg?
2. Для поддержки ситуации (с) Нпж Адрес Узла? прописки? ищется в постоянном печенье authto=..., которое выдаётся после первой успешной межузловой авторизации этого пользователя через ситуацию (a) или (b)
3. Обладая адресом узла? прописки? узел Б формирует промежуточную страницу?, содержащую:
   • iframe, запрашивающий документ по адресу: www.npj-nоde-A.ru/auth?for=tempid?
   • Javascript, определяющий успешное завершение этого запроса и инициирующий переход на саму запрошенную в урле страницу
   • явную ссылку/кнопку, осуществляющую такой переход (на случай отключения javascript или malfunction узла А)
   • явную ссылку/кнопку на скрипт подтверждения?, размещённый на узле А 
4. img/iframe из предыдущего пункта осуществляет запрос документа с узла А. Серверный скрипт, получающий этот запрос, проверяет факт авторизации пользователя А (по сеансовым или каким-то другим печеньям определяя Нпж Адрес Пользователя?) в системе, и, в случае успешной проверки, по http-протоколу обращается к узлу Б, передавая GET-запрос следующего вида:
   • www.npj-node-B.ru/authback?for=tempid?&user=lance@lrpg?&username=(urlencoded)?&sign=pass?
5. Узел Б, получая такой запрос, устанавливает в своей базе данных флаг авторизации данного пользователя и возвращает узлу А response в виде непустого документа, содержащего “Auth received”. Впрочем, содержимое документа не проверяется узлом А.
6. Узел А, получив удовлетворительный ответ от узла Б, возвращает юзер-агенту документ, удостоверяющий успешность авторизации (например, зелёный пиксел)
7. Узел А, не получив ответа от узла Б (timeout, connection refused, 403, 404, 500), возвращает юзер-агенту документ, сигнализирующий о провале авторизации (например, жёлтый пиксел)
8. Узел А, проверив, что пользователь с поставленным в запросе адресом? не авторизован в системе, возвращает юзер-агенту документ, сигнализирующий о провале авторизации (например, красный пиксел)
9. В случае успешного получения документа от узла А юзер-агент через Javascript осуществляет нажатие на ссылку перехода к странице.
10. В случае неотработки (неполучения документа) авторизации пользователь может вручную перейти к странице по ссылке
11. В случае неотработки img / iframe -механизма пользователь может воспользоваться предоставленной ссылкой на скрипт подтверждения?, нажатие на которую приводит к переходу отправкой GET-запроса вида: www.npj-nоde-A.ru/auth?for=tempid?&getback=1
12. В случае получения узом А подобного запроса, узел А отрабатывает межсерверное взаимодействие с узлом Б по описанной выше схеме и перенаправляет (Location:) юзер-агента обратно на страницу (по Referer).