Какую еще можно узнать информацию о клиенте, помимо IP и OS???

в принципе, серверу доступно только то, что клиент сам о себе сообщил. А сообщенное клиентом поступает в заголовках. Смотри apache_request_headers и суперглобальный массив $_SERVER

Ну а если так, на словах, може кто скажет, какую информацию можно получить о клиенте, кроме IP и OS

web_VIP, 



скажет лучше всех. И ничего не перепутает, и не забудет. Выполните эту простую операцию и посмотрите в справочнике смысл ключей. Быстрее будет и пользы больше. Честное слово. А если что-то будет непонятно, возвращайтесь сюда с конкретным вопросом. Обязательно поможем

Это сообщение отредактировал(а) Golda - 9.2.2008, 17:09

Golda,
Пробовал, по этому и спрашиваю... получается что кроме IP и OS ничего не удается узнать о пользователе, никто ничего не скажет по этому поводу?

Ну как же ничего? Клиент присылает обычно массу информации. Например:

• HTTP_USER_AGENT - описание клиента (обычно броузера)
• HTTP_ACCEPT - форматы документов, с которыми он умеет работать
• HTTP_ACCEPT_LANGUAGE - языковые предпочтения. И эта настройка уже в большей степени описывает пользователя, чем броузер, поскольку чаще меняется пользователем в настройках броузера
• HTTP_ACCEPT_ENCODING - поддерживает ли сжатие
• HTTP_REFERER - с какой страницы был переход 
• варианты типа HTTP_X_FORWARDED_FOR сообщают, что пользователь пришел через прокси и каков его настоящий IP

Другой вопрос, что все, что присылает клиент - ненаджный источник информации. Поскольку клиент может прислать и неправдивую информацию. Тут весь вопрос, для чего Вы собираете информацию о клиенте. Если Вы имеете в виду честных пользователей и собираете информацию, чтобы предоставить наиболее подходящий контент - пожалуйста, броузер сообщит и о операционной системе, и о предпочитаемом языке, и о принимаемых типах файлов, и о распозновании сжатых файлов. Делайте себе content negotiation наздоровье. Если же Вы пытаетесь вычислить "приметы" запросов хакера, 100% доверять этим данным нельзя 

Ладно, разьясню задачу, есть скрипт авторизаций для пользователей, что бы пользователь при каждом посещений сайта не вводил свои логин, вот и думаю как бы его так запомнить что бы облегчить ему работу на сайте.

web_VIP, записывайте в кук и в базу значение. и сверяйте. какие проблемы?

сессии.

Не в тему совет. Она же уничтожаетцо после закрытие браузера.

или я вру?

да, в принципе, лучше только coockie. хотя, если смотреть на вопрос чисто теоретически, то параметр session.coockie_lifetime можно установить любое ненулевое значение: тогда сессии не будут уничтожаться после закрытия окна браузера.

Добавлено через 57 секунд

скажем так, не в любом случае прав.

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

md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['HTTP_ACCEPT_ENCODING']) 

А в базе хранить флаг-признак того, что пользователь пожелал остаться залогиненым

gta4kv 
Да проблем в общем никаких, просто вопрос был про то что кроме IP и OS получается чтомы ничего не можем узнать, так?

...причем вся эта масса сводится, таки, к IP и, скажем, не ОС, а, если быть более точным - браузеру. Что не принципиально.

Этот заголовок не сообщает ровным счетом ничего. 

skyboy, все-таки, сессии не годятся вовсе, а не "не в любом случае".

Golda, Для авторизации эти заголовки не годятся. Обычно или что-то случайное, которое пишется в базу, или вычисляемое по авторизационной информации клиента.

web_VIP, да, так.

Это сообщение отредактировал(а) GeneralElectric - 11.2.2008, 12:27

Не совсем так. Я уже писала, что 100% доверять информации, приходящей в HTTP - заголовках нельзя, поскольку она легко может быть подделана. Но не стоит все-таки забывать, что помимо борьбы с хакерами у нас с вами есть еще одна задача. А именно целевое назначение сайтаов и веб-приложений. Работа для обычных пользователей, для обычных броузеров и прокси, которые присылают адекватную информацию для того, чтобы сервер выдал им ответ в наиболее адекватной форме. 

Например, HTTP_X_FORWARDED_FOR информативен, когда клиент выходит из-за корпоративного прокси. Вспомним также, что изначальное назначение прокси-серверов - не сокрытие IP-адреса клиента, а кеширование информации для сокращения трафика и ускорения ответа пользователю.

Резюмируя, можно сказать, что набор HTTP - заголовков - хороший источник информации для content negotiation, но плохой (поскольку ненадежный) - для вопросов, связанных с авторизацией.



Да, пожалуй, это более надежный вариант