[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Где хранить имя пользователя если не в куках?
Страницы: 1, 2, 3
VeRTak
Цитата (S.Chushkin @ 9.08.2015 - 16:22)
Какова у вас нагрузка? (в хитах, где обрабатывается sid)


Откуда я знаю) Я только начал изучать php) Просто хочется сразу делать так как положено!
S.Chushkin
Тогда забудьте про это и храните там, где Вам удобнее.
Когда дорастёте до средних нагрузок, вопрос сам собой отпадёт.

Изучайте базовые вещи, а тонкости отложите до уровня мидла.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Миша
Цитата (S.Chushkin @ 9.08.2015 - 16:26)
Тогда забудьте про это и храните там, где Вам удобнее.
Когда дорастёте до средних нагрузок, вопрос сам собой отпадёт.

Изучайте базовые вещи, а тонкости отложите до уровня мидла.

Что получаем в итоге, нормально дёргать БД при каждом обращении?
Или записать в сессию и при превышении лимита по времени - проверять?
Или ещё как? wink.gif

_____________
Принимаю заказы, писать в ЛС
S.Chushkin
Цитата (Медведь @ 9.08.2015 - 16:36)
Что получаем в итоге, нормально дёргать БД при каждом обращении?

Нормально.

Цитата
Или записать в сессию и при превышении лимита по времени - проверять?
Или ещё как?  wink.gif

Мне кажется, вы (все) запутались в трёх соснах smile.gif
Если коротко:
Сессия - сеанс связи клиента с сервером.
SID - ИД сессии/сеанса.
Параметры/переменные сессии - данные, нужные только в течении сеанса.

Обычно, SID генерится на сервере, а хранится в куках на клиенте и передаётся на сервер при каждом запросе. Что будет делать сервер с этим SID - заморочки разраба и админа.
Как правило, с SID связаны т.н. параметры сесиии ($_SESSION, например), которые хранятся на сервере. Насколько знаю, есть три варианта их хранения:
- файлы (встроено в ПХП) /малонагруженные проекты - десятки/сотни в сек на сервер/
- БД (типа mySQL) /средненагруженные проекты - сотни/тысячи в сек/
- кеш (типа, memcached) /высоконагруженные проекты - тысячи/десятки_тысяч в сек/

Обычно в сессионных параметрах хранится небольшой объём данных, нужных только в течении сеанса.
В частности, в $_SESSION можно хранить ИД юзера, чтобы при генерации страницы загружать его параметры (в т.ч. и волнуемое ТС "имя пользователя", хотя это всего-навсего 1/100 свойств юзера) и далее уже формировать страницу с учётом этих (и не только) данных.
Зачастую параметры сессии используют для расчёта статистики времени нахождения посетителя на сайте, число заходов и т.п.

Как-то так... А вообще, в инете полно статей по этому поводу, просто надо внимательно прочитать несколько и всё будет понятно, более или менее.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
stump
basic autorize

_____________
Трус не играет в хокей
Zzepish
Arh
Цитата
$_SERVER['HTTP_USER_AGENT']

Имхо- защита не о чем такого рода. Как показывает моя недавняя практика работы с заголовками на жабе через сокеты - можно подделать достаточно легко
Arh
Zzepish
Понятное дело. Просто несколько лет назад я через открытые wifi утаскивал ключ для авторизации вконтакте, если бы там была хотя бы такая проверка, я бы поленился менять браузер или вообще бы не понял что там такая проверка стоит.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Zzepish
Arh
как аргумент для ленивых biggrin.gif в серьезных проектах- не серьезная защита.
Arh
Zzepish
Понятное дело.
Да и по сути если утащили куки, то это проблема юзера.
вконтакте вполне так тянет на серьёзный проект, но даже такую мини-защиту не сделали.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Zzepish
Arh
ну- это да.
По хорошему- стоит в хеш вносить еще и ip. НО! Тогда как быть с людьми с динамическим IP.
killer8080
Цитата (Arh @ 10.08.2015 - 04:12)
Да и по сути если утащили куки, то это проблема юзера.

если девушка залетела, это проблема девушки
наше дело не рожать сунул, вынул, и бежать biggrin.gif
Абсурдное утверждение не находишь? Как рядовой юзер должен защищать куки от перехвата по твоему? Рядовому юзеру нет никакого дела ни до каких кук, открою секрет, подавляющее большинство юзеров ламеры, и они понятия не имеют что такое куки, да и не нужно оно им. А вот обезопасить трафик от снифинга, и потенциальных XSS может только разраб! И это его прямая обязанность, а не перекладывать с больной головы на здоровую!
Цитата (Arh @ 10.08.2015 - 04:12)
вконтакте вполне так тянет на серьёзный проект, но даже такую мини-защиту не сделали.

Едва ли ВК можно считать эталоном, проект крупный -да, высоконагруженный - да. Но безопасность у них никогда не была на высате. Те же фото в скрытых фотоальбомах защищены только через security through obscurity. Доступ к файла не контролируется никак.
Arh
killer8080
Цитата
если девушка залетела, это проблема девушки

Если у тебя спёрли ключи от квартиры, виноват изготовитель замков? =)

Я это к тому, что лучше так чем ничего.
"Zzepish: Имхо- защита не о чем такого рода."

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
killer8080
Цитата (Arh @ 11.08.2015 - 12:30)
Если у тебя спёрли ключи от квартиры, виноват изготовитель замков? =)

Аналогия не корректна, изготовитель замка никак не может защитить тебя от кражи ключей, а вот защитить, точнее в разы увеличить цену взлома, от перехвата трафика в твоих силах. Попробуй зайти в гугл по http:// wink.gif
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.