По поводу авторизации по cookie ты меня не совсем понял.
Немного теории. Стандартный механизм авторизации предполгает создание на сервере идентификатора сессии, и специального файла с данными самой сессии, имя которому - уникальный идентификатор. Каждому пользователю от сервера отправляется свой, уникальный идентификатор, который в браузере сохраняется в cookie, и передается обратно на сервер с каждым запросом. Таким образом сервер, по полученному от пользователя sessionid, явно понимает из какого файла взять данные пользователя. Именно так реализовано во всоле, и на всех сайтах, где есть авторизация пользователя чрез форму авторизации. Ну это ты и так без меня знаешь.
Я предлагаю следующую схему. Пользователь вводит в браузере: http://www.services.vint.ru/?secretword. То, что введено после знака "?" является паролем. Сервер получает запрос, получает строку "secretword", в php ее можно взять из $_SERVER['QUERY_STRING'], наверняка в java есть аналогичные механизмы. Затем сервер сравнивает полученную строку со значением, которое жестко прописано в коде. Если значения совпали, сервер устанавливает пользователю cookie, и отправляет ответ в браузер. Установить cookie средствами php можно так: setcookie('name', 'value', 'timelive', 'path'); Все, что нужно делать дальше, это проверять установлена ли нужная cookie, если да, то отображать форму добавления новости.
Этот механизм отличается от стандартного тем, что не нужно реализовывать форму авторизации и базу пользователей, что сокращает время разработки. Пароль достаточно передавать в QUERY_STRING, либо GET параметром. Если необходимо разным пользовтелям назначить разные пароли, то можно передавать два GET параметра: ?name=vasya&pass=vasyasecretword
Явные минусы этого подхода в том, что это менее безопасно. Как минимум потому, что история запрошенных url сохраняется в браузере. Любой кто имеет доступ к компьютеру - может получить доступ к паролю. Еще один момент, при каждом запросе на сервер передается http заголовок "referer", который содержит предыдущий посещенный url пользователем. Это тоже ведет к проблемам безопасности. Но у нас вроде не настолько серьезный ресурс, чтобы настолько заботиться о безопасности...
Впринципе, можно вместо установки cookie стартовать сессию. Но назначение механизма сессии несколько другое. И в этом случае не совсем ясно что в сессию сохранять, и на что закладываться при проверке доступа к форме добавления новости.
Вобщем, идею я высказал, а решение о том как реализовывать за тобой |