Разное

Я зарегистрированный пользователь этого форума. То есть, имею логин и пароль для создания постов.

И вот я вхожу на этот форум, используя браузер, с которого я сюда еще не входил. Кликаю на форму входа, ввожу логин и пароль, и кликаю «Ввод». При этом введенные мною логин/пароль тем или иным образом сопоставляются с данными о пользователях, имеющихся в базе. Если сопоставление дало положительный результат, то…

Вот с этого момента хочется разобраться поподробнее, что происходит после того, как пользователь опознан. Как создается Cookie и задаются его параметры, куда делается запись Cookie и что происходит при переходе на следующую страницу.

Можете рассказать об этом поподробнее? Чтобы алгоритм был полностью ясен?


(Речь не идет именно об этом конкретном форуме. Я на него сослался только для большей практичности вопроса).

При этом введенные мною логин/пароль тем или иным образом сопоставляются с данными
Это обычная авторизация, создается сессия (автоматически устанавливается кукис с идентификатором сессии) при переходе на следующую страницу браузер отсылает кукис с идентификатором сессии, и скрипту становятся доступны все сессионные переменные установленные на предыдущей странице
Это не обязательно форум, так работает все, что имеет регистрацию.

Это обычная авторизация.
Это не обязательно форум, так работает все, что имеет регистрацию.

Разумеется.

Можем пройтись по шагам?

Итак, прошла проверка пары логин/пароль. Далее:

1. setcookie (Например, setcookie ("music", "man40", time() + 600))
или session_start() ?

2. Переходим на другую страницу. И что конкретно происходит (желательно в деталях)?

вот неплохая статья http://true-coder.ru/php/pishem-avtorizaciyu-na-php.html
хотя хранить в кукисах пароль, даже хешированный я бы не стал
для авторизации устанавливать cookie не обязательно, в принципе, это относится к механизму автологина и для этого вместо хешированного реального пароля пользователя, надо генерировать специальный пароль автологина (который может подразумевать ограниченные права и который может меняться время от времени)
механизм сессии session_start() сам автоматически устанавливает cookie (имя переменной можно переопределить для пущей важности, но если куки сопрут, то сопрут все без исключения :) )

session_start() скажем так априори
на первой странице пишем необходимые настройки, переменные и все что угодно в $_SESSION
на другой странице достаем из $_SESSION все что нужно и можем поменять / добавить / удалить любые элементы
__
а вообще система регистрации / аутентификации / авторизации - это достаточно сложная штука, для глубокого понимания философии которой необходимо прочитать не одну книгу.

Статья замечательная, я её знаю.

Хочу пояснить, откуда ноги растут.

Возникла потребность пристыковать к сайту сервис, находящийся на компе в офисе. Инструкция по их стыковке существует, алгоритм описан. Стыковка не сложна, но поначалу сам я не стал с ней возиться, поскольку со всеми этими кукисами можно долго копаться, если нет достаточного навыка.

Привлек к работе поочередно пять (!) фрилансеров, и ни один из них с задачей не справился! Тема стыковки обсуждалась на трех профильных форумах – бесполезняк!

В конце концов пришлось самому досконально разбираться, как эти кукисы зарождаются и куда что пишется. Для примера взял авторизацию на форуме, но полной ясности и здесь нет.

Первым шагом, согласно инструкции, сайт при обращении к нему должен через HTML выдать удаленному компу имя Cookie и значение Cookie. И относительно Cookie это всё, что в инструкции сказано.

Должно ли ему предшествовать setcookie? Непонятно…

А если выполнить setcookie, то какой смысл в передаче удаленному компу через HTML имени Cookie и значения Cookie, если у него уже сидит сам файл Cookie?

Инструкцию прикрепить сюда можно?

Инструкция аналогична установлению связи с 1С:

Загрузка каталога из 1С в «1С-Битрикс: Управление сайтом»

Загрузка каталога начинается с того, что 1С отправляет http-запрос вместе с http-авторизацией следующего вида:
http://<сайт>/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth

На этот запрос система «1С-Битрикс: Управление сайтом» отвечает тремя строками (используется разделитель строк "\n"):
слово "success";
имя Cookie;
значение Cookie.

Примечание:
Все последующие запросы к 1С-Битрикс сопровождаются выставлением со стороны 1С имени и значения Cookie, полученными по команде "checkauth".
Далее следует запрос вида:
http://<сайт>/bitrix/admin/1c_import.php?type=catalog&mode=init

В ответ 1С-Битрикс выдает две строчки:
zip=yes, если сервер поддерживает обмен в zip-формате. В этом случае файлы на следующем шаге должны быть упакованы в zip-формате
или
zip=no, в таком случае файлы не должны быть упакованы, а передаются каждый по отдельности.
file_limit=<число>, где <число> - максимально допустимый размер файла в байтах для передачи за один запрос. Если размер файла больше, то он должен быть порезан на части.
Затем 1С запросами вида:
http://<сайт>/bitrix/admin/1c_exchange.php?type=catalog&mode=file&filename=<имя файла>
загружает на сервер файлы обмена в формате CommerceML 2, посылая содержимое файла или его части в виде POST.

В случае успешной записи файла 1С-Битрикс выдает "success".
На последнем шаге по запросу из 1С проводится пошаговая загрузка каталога:
http://<сайт>/bitrix/admin/1c_exchange.php?type=catalog&mode=import&filename=<имя файла>

Во время загрузки система «1С-Битрикс: Управление сайтом» может отвечать в одном из следующих форматов:
Если в первой строке содержится слово "progress" - это означает необходимость послать тот же запрос повторно. В этом случае во второй строке будет возвращен текущий статус обработки, объем загруженных данных, статус импорта и т.д.
Если в строке содержится слово "success", то это сообщает об успешном окончании обработки файла <имя файла>.

Примечание:
Если в ходе какого-либо запроса произошла ошибка, то ответ системы 1С-Битрикс будет иметь вид: в первой строке слово "failure", а на следующих - описание ошибки, произошедшей в процессе обработки запроса.

Если произошла необрабатываемая ошибка уровня ядра продукта или sql-запроса, то в таком случае будет возвращен html-код.

Инструкция аналогична установлению связи с 1С:
сильно смущает эта строка
как я понимаю у вас либо сайт не на 1С-Битриксе, либо сервис на компе не 1С

И сервис на компе не на 1С, и на на сайте не Битрикс.

Сервис на компе работоспособен, поскольку в качестве теста он успешно соединяется с демо-сайтом на Битриксе.

Что же касается скрипта на сайте, то его пока что нет, его и нужно сделать. Чтобы он выполнил те же функции, какие выполняются на Битриксе.

Вот такая стоит сейчас задача.

Будем думать, так даже интереснее

bitrix/admin/1c_exchange.php
bitrix/admin/1c_import.php

это то что надо расковырять
и про 1С отправляет http-запрос вместе с http-авторизацией не забыть

"это то что надо расковырять"

По этому пути как раз и пошел один из фрилансеров. И утонул в дебрях ООП. Там столько наворочено, что разобраться оказалось намного сложнее, чем в таком, в общем-то, элементарном процессе, как типовой протокол обмена.

Хорошо что вы подняли эту тему. Во что я заметил
смотрите значение куки wrdp
пароль можно свободно читать
а я думал, что както оно будеть защещен с помощю md5();
кто небуд может этого обяснить?

>Вот с этого момента хочется разобраться поподробнее, что происходит после того, как пользователь опознан. Как создается
>Cookie и задаются его параметры, куда делается запись Cookie и что происходит при переходе на следующую страницу.
Создается токен - уникальный индентификатор, который закрепляется за пользователем и сообщает, что он авторизован. Как правило, он помещается в сессию или в cookie. Сервер требует у клиента установить cookie (с токеном или с идентификатором сессии) при помощи HTTP-заголовка Set-Cookie. Получив такой HTTP-заголовок, браузер или интеллектуальный агент (бот) отправляет каждый следующий запрос HTTP-заголовок Cookie и сервер может отделить из всей массы запросов именно того пользователя, за которым закреплен токен.