LINUX.ORG.RU

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

 ,


1

1

Уважаемые форумчане! Требуется ваша помощь!

Подскажите, как правильно?

вариант 1)

  • Пользователь заходит на сайт.
  • Заходит на определённую страницу сайта.
  • Делаем запрос в базу данных, можно ли ему эту страницу видеть.
  • И так про каждую страницу на которую он заходит.

вариант 2)

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

В первом варианте минус - куча запросов в базу данных, во втором - теоретически огромный массив

В принципе я думаю что первый вариант лучше, но есть сомнения, поэтому решил спросить

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

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

Deleted
()

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

hippi90 ★★★★★
()
Ответ на: комментарий от Deleted

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

tonchikp
() автор топика
Ответ на: комментарий от surefire

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

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

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

Омфг.

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

x3al ★★★★★
()
Ответ на: комментарий от tonchikp

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

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

Deleted
()

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

x3al ★★★★★
()
Ответ на: комментарий от Deleted

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

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

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

surefire ★★★
()
Ответ на: комментарий от x3al

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

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

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

x3al ★★★★★
()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

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

surefire ★★★
()
Ответ на: комментарий от surefire

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

Deleted
()
Ответ на: комментарий от surefire

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

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

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

tonchikp
() автор топика
Ответ на: комментарий от tonchikp

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

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

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

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

surefire ★★★
()
Последнее исправление: surefire (всего исправлений: 1)
Ответ на: комментарий от surefire

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

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

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

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

gruy ★★★★★
()

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

fMad ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.