Ага, уже понял. Заголовок сообщества почему-то ушёл из внимания, а код похож на перловый. Чтобы в следующий раз не забывал, куда пишу, в карму уже наминусовали =)
Такие вещи решаются другими средствами =)
Не давайте доступ к администрированию людям, которым не доверяете. Потому что доступ будет отрубаться уже после того, как человек напортачит и лаг в 1 час ничего не изменит =)
Ну зачем такой жесткач. Либо всё время доверять кукам, либо всё время лазить в БД.
Совместное использование неприемлемо? Сравнивайте с БД на здоровье. Но не каждый хит, а, скажем, раз в час.
Но Вы, вероятно, не об этом, да? Цифровая подпись может быть в виде CRC32, например. Цифовая подпись и сертификат, выданный в каком-нибудь Verisign, не синонимы.
Задача цифровой подписи - подтвердить валидность данных. В случае с электронным письмом, например, имеет значение не только гарантия валидности данных (неизменности текста письма), но и гарантия валидности отправителя - сертификат решает обе эти задачи.
Не мог бы =)
Во-первых, я не очень общительный и новые контакты завожу неохотно.
Во-вторых, логику я описал уже внизу, дальше фантазируйте сами. Perl я не знал, да ещё и забыл.
В-третьих, есть отличная статья.
А лучше данный метод тем, что меньше соблазнов делать абсолютно немасштабируемое приложение.
Во-первых, тестил, небось, на двух записях в таблице, да? Где уникальный индекс на поле с логином? Знаешь, во сто крат надёжнее, правильнее и красивее иметь уникальный индекс, а не выделываться с лотереей "а вдруг никто не успеет между select и insert вставить запись с таким же логином". И select в функции регистрации нафиг не нужен сразу становится, а чем меньше запросов к БД, тем дольше живёшь.
Во-вторых, что это за такой мегарулез, каждый раз лазить в базу для аутентификации? Дешевле зашифровать в куку подписанные нужные данные. Масштабировать БД существенно сложнее, чем масштабировать BL. В случае, когда кто-нибудь начнёт присылать вам в куках какой-нибудь мусор, ни один аутентифицированный пользователь не сможет зайти на сайт, потому что забьют мусором коннекшены к БД пользователей. Дешифровать небольшую строку и проверить подпись существенно быстрее, чем сделать запрос к БД.
В-третьих, сколько уже можно писать код для SQL-инъекций? Я не верю, что DBI перестал поддерживать параметры (мегаязык Perl не использую уже лет пять). Это _единственный_ способ обезопасить себя от SQL-инъекции. А смехопанорамные проверки регэкспами и эскейпы ерунда.
В-чётвёртых, строка $login = $_POST['login']; идёт хрен знает какой по всему коду. Я не понимаю, зачем везде использовать "$_POST['login']", это же каждый встреченный раз даёт возможность на опечатку!
В-пятых, в-шестых, в-седьмых, ..., в-стовосемдесятдевятых - всё это есть в куче книг и статей. Ё-маё, уже в переводах есть практически любая западная литература. Почему вы бросаетесь решать какие-то мегапроблемы мегазащит от мегахакеров не умея кодировать?!
Да ещё авторизация. Я плачу. Какая это авторизация? То, что описано выше, это аутентификация. А авторизация начнётся, когда автор сделает аналог ACL. В самом тривиальном случае авторизации Id пользователя надо хоть с чем-нибудь сравнить, чтобы понять, давать ему доступ к функциональности или не давать.
Разрешение у меня 1600х1200.
В таком разрешении практически все сайты отстой.
На маковских аналогичных мониках разрешение 1920 на сколько-то там. То есть, всё ещё хуже. Потому, собственно, у Маков и не разворачивают окна - мониторы здоровые слишком башней вертеть =)
Но в основном народ ходит с 1280 и 1024 по ширине, потому разворачивает окна на весь экран.
Мы рассматриваем разные стили, что ли, работы. Я считаю, что создать что-то хорошее и красивое может только команда. Набор сотрудников любой квалификации под эгидой менеджерства в лучшем случае сделают хорошо что-то обыденное.
Я считаю также, что рассматривать людей как чёрные ящики с набором функционала неэффективно.
В общем, в моём понимании мира управляющие менеджеры хорошо ложатся на клерков в банках и продавцов пирожков. А когда надо делать что-то головой, нужны другие способы.
Не имейте клиентов!
Тогда винить будет некого, кроме себя =)
Менее брутальный вариант, это быть Лебедевым и иметь возможность выбирать, с кем работать.
Но я, всё-таки, не верю в управляющих менеджеров проектов. Они нужны в очень-очень узком кругу задач. В Peopleware писали, что бухгалтерские программы пишутся тоннами, технология их написания известна и всё такое. Но при этом незавершённых проектов бухгалтерских программ море. Вместо бухгалтерской программы можно поставить сайт и любое другое не очень сложное произведение.
У нас был менеджер проектов. Несколько раз. Но его наличие вообще никак ни на что не влияло. Если бы надо было делать сайты типа Делла, IBM или Микрософт, наверное менеджер нужен был. Потому что там требуется много людей и их надо между собой как-то синхронизировать и всё такое. Если пытаться синхронизировать 3-4 человека, получается либо ерунда, либо никакого влияния.
Ну это ничего страшного, что не видите. Некоторые хернёй маются, а некоторые развлекаются =)
Я осуждаю людей, которые вместо работы играют в игры, при этом я сам играю в игры. Но не вместо работы, а в качестве развлечения. С болтанием в таких дискуссиях то же самое.
Не давайте доступ к администрированию людям, которым не доверяете. Потому что доступ будет отрубаться уже после того, как человек напортачит и лаг в 1 час ничего не изменит =)
Совместное использование неприемлемо? Сравнивайте с БД на здоровье. Но не каждый хит, а, скажем, раз в час.
Но Вы, вероятно, не об этом, да? Цифровая подпись может быть в виде CRC32, например. Цифовая подпись и сертификат, выданный в каком-нибудь Verisign, не синонимы.
Задача цифровой подписи - подтвердить валидность данных. В случае с электронным письмом, например, имеет значение не только гарантия валидности данных (неизменности текста письма), но и гарантия валидности отправителя - сертификат решает обе эти задачи.
Про плейсхолдеры - это кто по что горазд. Обычно они вопросами вставляются в запросы. Вероятно, терминология в разных фреймворках различается.
Во-первых, я не очень общительный и новые контакты завожу неохотно.
Во-вторых, логику я описал уже внизу, дальше фантазируйте сами. Perl я не знал, да ещё и забыл.
В-третьих, есть отличная статья.
А лучше данный метод тем, что меньше соблазнов делать абсолютно немасштабируемое приложение.
А сессии это лузерство.
Автор, это не ты случаем предлагаешь на http://supercreativ.narod.ru/ обучение занедорого? =)
Во-первых, тестил, небось, на двух записях в таблице, да? Где уникальный индекс на поле с логином? Знаешь, во сто крат надёжнее, правильнее и красивее иметь уникальный индекс, а не выделываться с лотереей "а вдруг никто не успеет между select и insert вставить запись с таким же логином". И select в функции регистрации нафиг не нужен сразу становится, а чем меньше запросов к БД, тем дольше живёшь.
Во-вторых, что это за такой мегарулез, каждый раз лазить в базу для аутентификации? Дешевле зашифровать в куку подписанные нужные данные. Масштабировать БД существенно сложнее, чем масштабировать BL. В случае, когда кто-нибудь начнёт присылать вам в куках какой-нибудь мусор, ни один аутентифицированный пользователь не сможет зайти на сайт, потому что забьют мусором коннекшены к БД пользователей. Дешифровать небольшую строку и проверить подпись существенно быстрее, чем сделать запрос к БД.
В-третьих, сколько уже можно писать код для SQL-инъекций? Я не верю, что DBI перестал поддерживать параметры (мегаязык Perl не использую уже лет пять). Это _единственный_ способ обезопасить себя от SQL-инъекции. А смехопанорамные проверки регэкспами и эскейпы ерунда.
В-чётвёртых, строка $login = $_POST['login']; идёт хрен знает какой по всему коду. Я не понимаю, зачем везде использовать "$_POST['login']", это же каждый встреченный раз даёт возможность на опечатку!
В-пятых, в-шестых, в-седьмых, ..., в-стовосемдесятдевятых - всё это есть в куче книг и статей. Ё-маё, уже в переводах есть практически любая западная литература. Почему вы бросаетесь решать какие-то мегапроблемы мегазащит от мегахакеров не умея кодировать?!
Да ещё авторизация. Я плачу. Какая это авторизация? То, что описано выше, это аутентификация. А авторизация начнётся, когда автор сделает аналог ACL. В самом тривиальном случае авторизации Id пользователя надо хоть с чем-нибудь сравнить, чтобы понять, давать ему доступ к функциональности или не давать.
В таком разрешении практически все сайты отстой.
На маковских аналогичных мониках разрешение 1920 на сколько-то там. То есть, всё ещё хуже. Потому, собственно, у Маков и не разворачивают окна - мониторы здоровые слишком башней вертеть =)
Но в основном народ ходит с 1280 и 1024 по ширине, потому разворачивает окна на весь экран.
Я считаю также, что рассматривать людей как чёрные ящики с набором функционала неэффективно.
В общем, в моём понимании мира управляющие менеджеры хорошо ложатся на клерков в банках и продавцов пирожков. А когда надо делать что-то головой, нужны другие способы.
Тогда винить будет некого, кроме себя =)
Менее брутальный вариант, это быть Лебедевым и иметь возможность выбирать, с кем работать.
У нас был менеджер проектов. Несколько раз. Но его наличие вообще никак ни на что не влияло. Если бы надо было делать сайты типа Делла, IBM или Микрософт, наверное менеджер нужен был. Потому что там требуется много людей и их надо между собой как-то синхронизировать и всё такое. Если пытаться синхронизировать 3-4 человека, получается либо ерунда, либо никакого влияния.
Я осуждаю людей, которые вместо работы играют в игры, при этом я сам играю в игры. Но не вместо работы, а в качестве развлечения. С болтанием в таких дискуссиях то же самое.
http://www.habrahabr.ru/company/bolotov/