-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Поругайте авторизацию и межстраничную валидацию пользователя.
- Автор темы igortik
- Дата начала
- Статус
igortik
Новичок
В итоге:
1. Я убрал экранирование кавычек для переменной с паролем.
2. Примерно для себя понял, что можно рассматривать вопрос введения сессий, но пока смутно понимаю его надобность.
Остается вопрос по скорости работы базы при том, что я буду тянуть одним запросом на каждой странице из таблицы `users_login_session` либо `hash`, либо `user_id`.
Логически понятно, что первый метод будет медленне.
Если записей в таблице 100 .. а если 1000.. ведь на каждого юзера будет своя уникальная запись.
P.S. Действующий проект имеет более 300 хостов в сутки, не учитывая того, что он будет новым, грамотное SEO, проф. дизайн, как следствие - увеличение хостов прогнозировано.
-~{}~ 23.06.09 14:15:
*****
Ты прав.
Я именно так и мыслю, но допустил ошибку на автомате, т.к. всегда экранирую переменные при необходимости (при подстановке в запросы) и скорее они туда попали копи-пейстом
1. Я убрал экранирование кавычек для переменной с паролем.
2. Примерно для себя понял, что можно рассматривать вопрос введения сессий, но пока смутно понимаю его надобность.
Остается вопрос по скорости работы базы при том, что я буду тянуть одним запросом на каждой странице из таблицы `users_login_session` либо `hash`, либо `user_id`.
Логически понятно, что первый метод будет медленне.
Если записей в таблице 100 .. а если 1000.. ведь на каждого юзера будет своя уникальная запись.
P.S. Действующий проект имеет более 300 хостов в сутки, не учитывая того, что он будет новым, грамотное SEO, проф. дизайн, как следствие - увеличение хостов прогнозировано.
-~{}~ 23.06.09 14:15:
*****
Ты прав.
Я именно так и мыслю, но допустил ошибку на автомате, т.к. всегда экранирую переменные при необходимости (при подстановке в запросы) и скорее они туда попали копи-пейстом
igortik
Новичок
*****
Суть таблицы `users_login_session` такова:
1. При регистрации юзера создается уникальная запись для него по его ID
2. Как только юзер логинится - в поле `hash` его записи в таблице генерируется значение
3. Также значение `hash` будет меняться в случае вылогинивания.
Т.е. фактически мы имеем относительно редко обновляемую таблицу, т.к. апдейт записи происходит по факту логина или выхода из системы и при регистрации инсерт...
На домашних ПК кука будет жить год.... (подразумеваю юзание сайта на одном месте с одним браузером).
P.S. insert только по мере регистрации!
-~{}~ 23.06.09 14:45:
Вердикт?
Суть таблицы `users_login_session` такова:
1. При регистрации юзера создается уникальная запись для него по его ID
2. Как только юзер логинится - в поле `hash` его записи в таблице генерируется значение
3. Также значение `hash` будет меняться в случае вылогинивания.
Т.е. фактически мы имеем относительно редко обновляемую таблицу, т.к. апдейт записи происходит по факту логина или выхода из системы и при регистрации инсерт...
На домашних ПК кука будет жить год.... (подразумеваю юзание сайта на одном месте с одним браузером).
P.S. insert только по мере регистрации!
-~{}~ 23.06.09 14:45:
Вердикт?
igortik
Новичок
*****
Фишка этой таблицы в том, что хеш для каждого юзера должен совпадать с хешем его куки.
Т.е. если кука левая, то хеши не совпадут и не будет валидации. (валидайия будет доступна у того, на чьем компе сгенерен верный хеш в куках)
Если же куку сперли, то в любой момент можно залогиниться снова или выйти из системы, чтобы обновить хеш в базе и злоумышленник не сможет войти.
Я использую эту таблицу в качестве аналога сессий.
Но преимущества ее, на мой взгляд, очевидны - не нужно открывать сессии, не нужно постоянно поддерживать их или устанавливать невероятное значение ее жизни.
-~{}~ 23.06.09 14:55:
и хеш будет всегда уникален, т.к. получается путем конкатенации переменных юзера (существующих на данный момент их значений) + time();
Фишка этой таблицы в том, что хеш для каждого юзера должен совпадать с хешем его куки.
Т.е. если кука левая, то хеши не совпадут и не будет валидации. (валидайия будет доступна у того, на чьем компе сгенерен верный хеш в куках)
Если же куку сперли, то в любой момент можно залогиниться снова или выйти из системы, чтобы обновить хеш в базе и злоумышленник не сможет войти.
Я использую эту таблицу в качестве аналога сессий.
Но преимущества ее, на мой взгляд, очевидны - не нужно открывать сессии, не нужно постоянно поддерживать их или устанавливать невероятное значение ее жизни.
-~{}~ 23.06.09 14:55:
и хеш будет всегда уникален, т.к. получается путем конкатенации переменных юзера (существующих на данный момент их значений) + time();
igortik
Новичок
*****
Я эстетически хотел разделить данные логов посещений (last_login), ip и т.д. от таблицы юзеров.
Под аналогом я имел ввиду механизм аутентификации, т.к. проверяются 2 значения на совпадение, как в случае с сессиями (при условии отсутствия иных переменных сессии и их проверки).
Но преимущества в том, что перехватив куку - в любой момент вся процедура ее перехвата теряет свой смысл, если юзер вышел или снова зашел с другого компа.
Т.е. уже эта задумка имеет право на жизнь, т.к. проблема типичная для всех пользователей - забыть нажать кнопку "выход".
Да и программно этот способ, на мой взгляд, более гибкий, чем сессии, т.к. нет смысла ломать голову, как ее продлить (сессию) ... исключая рефреши страниц..
Также можно еще и вылогинивать вообще всех юзеров, стирая их хеши, у кого ласт_тайм_визит более 1 дня и т.д.
-~{}~ 23.06.09 15:09:
p.s. как-то моя подруга лазила в контакте на моем компе.. а я уже сто лет им не пользуюсь .. и по факту обращения клиента провести там контекстную рекламу я был изумлен, увидев ее анкету, пройдя по урлу ресурса.
Кука 3-х месячной давности была причиной. А ведь этого могло и не произойти...
ровно, как и если бы иной метод авторизации использовался бы ...
на сессиях, но что-то мне интуиция подсказывает, что незря на таком ресурсе нет этого метода валидации юзера..
могу ошибаться конечно же.
-~{}~ 23.06.09 15:10:
p.s. и при любых я стремлюсь написать код один раз, прежде, чем его отправить в работу, потому и пытаюсь найти идеальное решение среди идеальных намерений
-~{}~ 23.06.09 15:16:
Так я так и не понял для себя одного - насколько медленнее будет идентификация пользователя и его валидация по хешу кук (в моем случае) ?
Я эстетически хотел разделить данные логов посещений (last_login), ip и т.д. от таблицы юзеров.
Под аналогом я имел ввиду механизм аутентификации, т.к. проверяются 2 значения на совпадение, как в случае с сессиями (при условии отсутствия иных переменных сессии и их проверки).
Но преимущества в том, что перехватив куку - в любой момент вся процедура ее перехвата теряет свой смысл, если юзер вышел или снова зашел с другого компа.
Т.е. уже эта задумка имеет право на жизнь, т.к. проблема типичная для всех пользователей - забыть нажать кнопку "выход".
Да и программно этот способ, на мой взгляд, более гибкий, чем сессии, т.к. нет смысла ломать голову, как ее продлить (сессию) ... исключая рефреши страниц..
Также можно еще и вылогинивать вообще всех юзеров, стирая их хеши, у кого ласт_тайм_визит более 1 дня и т.д.
-~{}~ 23.06.09 15:09:
p.s. как-то моя подруга лазила в контакте на моем компе.. а я уже сто лет им не пользуюсь .. и по факту обращения клиента провести там контекстную рекламу я был изумлен, увидев ее анкету, пройдя по урлу ресурса.
Кука 3-х месячной давности была причиной. А ведь этого могло и не произойти...
ровно, как и если бы иной метод авторизации использовался бы ...
на сессиях, но что-то мне интуиция подсказывает, что незря на таком ресурсе нет этого метода валидации юзера..
могу ошибаться конечно же.
-~{}~ 23.06.09 15:10:
p.s. и при любых я стремлюсь написать код один раз, прежде, чем его отправить в работу, потому и пытаюсь найти идеальное решение среди идеальных намерений
-~{}~ 23.06.09 15:16:
Так я так и не понял для себя одного - насколько медленнее будет идентификация пользователя и его валидация по хешу кук (в моем случае) ?
С эстетикой тебе не сюда, а на сайт третьяковской галереи.
С технологической точки зрения ты просто разделил одну таблицу на две, без каких-либо реальных причин.
И перестань упоминать сеансы или сессии. У тебя никаких сеансов, или их аналогов, на сайте не используется.
а это еще что за новости и откуда оно взялось? ласт_тайм_логин ты хотел сказать? и какая от него польза?
-~{}~ 23.06.09 15:27:
Что-то у тебя реплики все тупее и тупее становятся.
Тебе сказали уже, что скорость не будет иметь значения. Ты можешь уже понять это и перестать долбить, как дятел один и тот же вопрос?
А по действительно важным вопросам идеологии у тебя один ответ - божья роса.
Ты путаешь авторизацию и запоминание пользователя. Это две разные операции, а у тебя в голове это одно и то же. При этом запоминание всегда должно быть опциональным. При этом нежелательно привязывать его IP.
igortik
Новичок
*****
Да, именно, чтобы, например, анализировать активность аудитории.
Аналитические данные лишними не бывают в вопросах рекламы, учитывая, что компания-заказчик уделяет большое значение всем ее направлениям.
А что касается эстетики - ты не прав.
Ты сам знаешь, что существуют правила для оформления кода, чтобы могли работать другие разработчики и т.д.
И я не вижу смысла лепить все данные по юзеру в одну таблицу, т.к. если мне вдруг придет в голову совершенствовать механизм и во второй таблице придется завести еще одну запись для пользователя, то представляю себе уже объемы клонированных данных .... и т.д. хотя, можно под эту функцию и другую таблицу завести, но лучше все заранее продумать и учитывать расширение функционала. имхо.
Да и сама идея автора приложения имеет право существовать, главное, чтобы не в ущерб самому приложению.
Да, именно, чтобы, например, анализировать активность аудитории.
Аналитические данные лишними не бывают в вопросах рекламы, учитывая, что компания-заказчик уделяет большое значение всем ее направлениям.
А что касается эстетики - ты не прав.
Ты сам знаешь, что существуют правила для оформления кода, чтобы могли работать другие разработчики и т.д.
И я не вижу смысла лепить все данные по юзеру в одну таблицу, т.к. если мне вдруг придет в голову совершенствовать механизм и во второй таблице придется завести еще одну запись для пользователя, то представляю себе уже объемы клонированных данных .... и т.д. хотя, можно под эту функцию и другую таблицу завести, но лучше все заранее продумать и учитывать расширение функционала. имхо.
Да и сама идея автора приложения имеет право существовать, главное, чтобы не в ущерб самому приложению.
что ты несешь? какая активность аудитории?
вот я залогинился в сентябре. хожу каждый день по 5 раз.
в следующий раз меня попросило ввести пароль под новый год. И что тут тебе дадут твои анализы?
-~{}~ 23.06.09 15:32:
вот я залогинился в сентябре. хожу каждый день по 5 раз.
в следующий раз меня попросило ввести пароль под новый год. И что тут тебе дадут твои анализы?
-~{}~ 23.06.09 15:32:
это еще что за ересь? зачем вторая запись может понадобиться? можно избавить меня от совсем высосанных из пальца, в процессе написания поста придуманных реплик? спасибо
ласт_тайм_визит может существовать только при использовании сеансов. поскольку никаких сеансов у тебя не предуспотрено - пользователь считается залогиненым все время, независимо от того, работает он с сайтом, или нет, говорить о визитах не имеет смысла.
время же логина, при той же самой постоянной залогинености, тоже не имеет никакого смысла.
неужели так это сложно понять?
-~{}~ 23.06.09 15:36:
ясно. сдулся наш изобретатель.
пожалуй, тему можно закрывать, тут только практика поможет.
-~{}~ 23.06.09 15:39:
когда систему действительно поругали, по сути, а не по мелочи - тут же начались виляния и беллетристика про эстетику.
время же логина, при той же самой постоянной залогинености, тоже не имеет никакого смысла.
неужели так это сложно понять?
-~{}~ 23.06.09 15:36:
ясно. сдулся наш изобретатель.
пожалуй, тему можно закрывать, тут только практика поможет.
-~{}~ 23.06.09 15:39:
когда систему действительно поругали, по сути, а не по мелочи - тут же начались виляния и беллетристика про эстетику.
igortik
Новичок
ты не понял.
Я благодарен за разбор полетов ...
-~{}~ 23.06.09 15:43:
Но ...
Ласт тайм логин мне может помочь, например:
- обнуляю все хеши логинов (все юзеры не залогинены, или те, кто нам нужен)
- я опустил некоторые важные для клиента параметры, по которым классифицируется аудитория
- мы производим рекламу для аудитории и анализируем отклик на нее по заходам конкретно этой категории пользователей, конкретно в этот момент времени
Я благодарен за разбор полетов ...
-~{}~ 23.06.09 15:43:
Но ...
Ласт тайм логин мне может помочь, например:
- обнуляю все хеши логинов (все юзеры не залогинены, или те, кто нам нужен)
- я опустил некоторые важные для клиента параметры, по которым классифицируется аудитория
- мы производим рекламу для аудитории и анализируем отклик на нее по заходам конкретно этой категории пользователей, конкретно в этот момент времени
Да где ж у тебя отслеживается заход?!
Я зашел в сентябре. потом месяц не ходил. потом получил рекламу, зашел, не понравилось, ушел. в ласт тайм визит у меня сентябрь. что ты где тут отслеживаешь, я все понять не могу. на чем?!
на тех процентах, у которых сменился IP?
Я зашел в сентябре. потом месяц не ходил. потом получил рекламу, зашел, не понравилось, ушел. в ласт тайм визит у меня сентябрь. что ты где тут отслеживаешь, я все понять не могу. на чем?!
на тех процентах, у которых сменился IP?
igortik
Новичок
p.s. обычный счетчик хостов ничего не даст, т.к. нет классификации кто зашел и что хотел... а вот залогиненные в эту неделю пользователи, которые имеют в своем аккаунте определенный статус, например, клиент организации Х, - уже скажу о том, что рекламная кампания, нацеленная на этот круг прошла успешно и есть положительный отклик.
-~{}~ 23.06.09 15:48:
*****
Вот... тут ты прав, но никто не отменял update table set `hash`=''.
при этом все автоматом вылогиниваются.
Не совсем адекватно, но реально работающий метод для отслеживания конкретных групп пользователей.
-~{}~ 23.06.09 15:48:
ПРИ ОБНУДЕННОМ ХЕШЕ ЮЗЕР НЕ ЗАЛОГИНЕН!
-~{}~ 23.06.09 15:48:
*****
Вот... тут ты прав, но никто не отменял update table set `hash`=''.
при этом все автоматом вылогиниваются.
Не совсем адекватно, но реально работающий метод для отслеживания конкретных групп пользователей.
-~{}~ 23.06.09 15:48:
ПРИ ОБНУДЕННОМ ХЕШЕ ЮЗЕР НЕ ЗАЛОГИНЕН!
igortik
Новичок
*****
Предлагаю прекратить дебаты о профнепригодности.
Работа у меня была и есть всегда, и с каждым днем ее еще больше
Тебе благодарен за технические разъяснения.
p.s. твоя критика и высказывания часто в тему, что стимулирует самокритику для дальнейшего развития навыков, но иногда - пришей кобыле хвост
Предлагаю прекратить дебаты о профнепригодности.
Работа у меня была и есть всегда, и с каждым днем ее еще больше
Тебе благодарен за технические разъяснения.
p.s. твоя критика и высказывания часто в тему, что стимулирует самокритику для дальнейшего развития навыков, но иногда - пришей кобыле хвост
- Статус