Пользователь сайта и запросы в базу данных

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

Потом пользователь подделывает cookie и смотрит на что хочет. Бери первый вариант.

Первый вариант плюс кеширование на стороне сервера. По поводу второго варианта не забывай: все врут, клиент в руках врага. Ты никогда не можешь доверять данным, присылаемым с клиента.

во первых куки можно подписать от подделки, во вторых ты куки перепутал с сессиями.

Спасибо! Кстати, немного в сторону от темы вопрос: А насколько велика вероятность подделки IP-адреса?

во первых куки можно подписать от подделки

Можно и подписать, но лучше принимать решение на сервере, а не следовать тому, что дал клиент. Плюс давать весь набор разрешенных урлов с самого начала - не комильфо, т.к. чем меньше клиент получит информации - тем лучше, и по соображением безопасности, и по нагрузке на каналы связи и на браузер.

во вторых ты куки перепутал с сессиями.

Сессии, по-твоему, через что передаются?

Сессии, по-твоему, через что передаются?

Омфг.

Сессии могут храниться как угодно, в этом году самый популярный вариант — в куках ДЛИННЫЙ ключ сессии (размером с sha1 минимум), а сама сессия — в базе/redis'е. Этот длинный ключ перебирать будешь примерно до тепловой смерти Вселенной.

А насколько велика вероятность подделки IP-адреса?

Если ты про воспользоваться каким-то прокси, то раз плюнуть. Если ты про то, что известна сессия и привязанный адрес, то только через контроль над машиной, у которой есть этот адрес.

Не видел второго варианта нигде и не уверен, что он быстрее. Огромным он вряд ли будет если ты не буквально каждую страницу туда запихиваешь (обычно разрешают доступ к каким-нибудь overview.detailed или что-то в этом роде, а этот ACL даёт доступ к набору страниц).

во вторых ты куки перепутал с сессиями.

Сессии, по-твоему, через что передаются?

Содержание сессии клиенту ни через что не передаётся, клиенту через куки передается идентификатор сессии.

Сессии могут храниться как угодно, в этом году самый популярный вариант — в куках ДЛИННЫЙ ключ сессии (размером с sha1 минимум), а сама сессия — в базе/redis'е.

Тогда нужен будет запрос в базу, от чего ТС и пытался уйти.

Пользователь сайта и запросы в базу данных (комментарий)

Тогда нужен будет запрос в базу, от чего ТС и пытался уйти.

Эмм. Этот запрос —

* не обязательно в базу

* для получения ВСЕЙ информации о пользователе, не только auth.

Сессии неподписанными кукизами делали, наверно, годах в девяностых и то ССЗБ.

Не обязательно, кеш сессий может храниться в ОЗУ. Далее разница в том, что в сессии уже храниться готовый набор данных, который не нужно в очередной раз собирать, вычислять, фильтровать.

Но я не говорю, что сама идея ТС верная, обычно делают по другому.

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

Вы больше за какой вариант?

Но я не говорю, что сама идея ТС верная, обычно делают по другому

А как лучше сделать на Ваш взгляд?

Я больше за первый вариант.

Один простой лишний запрос в базу это мелочь.

Отпадает проблема административного управления, если ты захочешь добавить или убрать некий урл из доступных тебе не придётся сбрасывать сессии юзерам или просить их перелогиниться.

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

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

Спасибо Вам и всем участникам, развеяли мои сомнения и помогли определиться

• делаем некий /профиль/ доступа, скажем 'user' < 'moderator'< 'admin'
• имя профиля сохраняем в cookie, подписываем её hmac целиком
• при следующем запросе сервер проверяет целостность cookie, достаёт имя профиля, и предъявляет его конкретной страничке
• та сверяет со списком разрешённых и решает пущать или нет
• ???
• запросы в базу по этому поводу падают почти до нуля.

Странно, что никто еще про преждевременную оптимизацию ничего не сказал.

почитай про join в sql запросах