Этот пост предназначен для расширения сознания начинающих пэхэпэшников. Так сложилось, что в рунете термин "авторизация" используется в неправильном или в слишком широком смысле. Авторизация это разрешение на выполнение какого-то действия. Например право открыть определенную страничку. Или право на сдачу экзамена. Авторизован на… == Имеет право на… Для этого система должна знать с кем имеет дело, т.е. идентифицировать пользователя: он Вася или он Маша или он просто аноним (т.е. х*й с горы). Чтобы система его идентифицировала, ранее пользователь должен пройти аутентификацию, т.е. процедуру проверки логина и пароля. Аутентификацию, Карл, а не авторизацию! В процессе аутентификации система запоминает пользовательский идентификатор (как правило, в сесии или в куке). Пока пользователь НЕ прошел аутентификацию, по умолчанию идентифицируем его как "анонимного пользователя". Очевидно, что аноним "не авторизован" на некоторые действия. Но он "авторизован", например, на страницу ввода логина+пароля. Или на чтение страницы с инструкциями. Да прибудет с вами Сила!
Просто эти слова родились не в программировании. На самом деле, это вообще разные понятия. Аутентификация есть проверка аутентичности, по-русски - подлинности. Например, можно провести аутентификацию купюры, или картины, или останков царской семьи, и при этом никакая авторизация не будет рядом валяться. Авторизация есть процесс выдачи прав на какие-либо действия. Можно запомнить, какой вопрос задается к этим операциям: Аутентификация - чего? Авторизация - на что, для чего? Пример из жизни: вы приходите на КПП и предъявляете пропуск. Охранник кладет пропуск под ультрафиолет, проверяет водяные знаки и т.д. - аутентификация пропуска. Охранник сверяет сверяет фото в пропуске с вашим фейсом и читает Ф.И.О. - идентификация. Охранник находит ваше Ф.И.О. в белом списке и поднимает шлагбаум - авторизация. В программировании всё очень тесно.
Вася, спасибо за прекрасные пояснения! Кто-то скажет: а нафига вообще это знать, можно скопировать пример "авторизации" из интернетов и пользоваться — и пофиг как это называется. Проблема в том, что незнание основ приводит к нелепым ошибкам и дырам. Нубы регулярно спрашивают "я сделал авторизацию, а как мне теперь спрятать страницу куда делается переход?", или "у меня запросы по ajax, как защититься от кражи адреса?". То есть пацанчик не понимает, что авторизации у него как не было, так и нет, а есть самообман в виде странички с логином и паролем. Чтобы сделать, надо понимать что́ делаешь и зачем. Определения терминов: Авторизация Аутентификация Идентификация
Ну так со временем это приходит. Сначала человек делает страничку с логином и паролем. Потом задается вопросом, а чем отличается вход через нее от входа не через нее. Потом делает права доступа и проверку вида is_user() и is_admin(). Ему этого хватает на какое-то время. А потом уже дорастает до нормального ACL и групп. Проблема с тем, что какие-то страницы доступны по прямым ссылкам или по аяксу без авторизации, отпадает уже на второй стадии. Тогда человек понимает, что не важно, куда к нему стучатся и не важно как. Важно кто.
Этот топик создан для того чтобы их тыкать носом. Как в phpfaq.ru/debug/ ))) Тема-то одна из корневых. Если честно, я не припомню случаев "прозрения". Обычно два-три раза укажешь путь, они тихо сливаются. Бывают упоротые, которые талдычат "если такой умный, покажи как определить откуда юзер". А вот "спасибо, теперь дошло про авторизацию" не видел.
Проверять есть ли полномочия надо в контроллере, в единой точке входа ? Код (PHP): if ($_COOKIE['is_admin']) { //вывод для админа } else { //вывод формы для входа } Как то так ?
Проверять надо там, где это нужно. Например, нет смысла проверять права доступа для отображения шапки и подвала страницы, верно? А вот для отображения, например, модераторских инструментов - есть. И для обработки запросов к модулям, отвечающим за модераторские функции. Есть вот такая вот табличка в интернете. Там есть нулевой столбец, в котором есть кнопки для удаления строк и для выписывания бана по IP тому, кто ответ оставил. Но ты этот столбец не видишь. А я вижу. Проверка прав проводится только там, где система принимает решение, показывать эти кнопки или нет.
machetero, в своём примере ты накосячил, веришь пользователю на слово. реализации могут быть разными и не все любят буквы MVC. сейчас стал модным термин MiddleWare, можно там что-то проверять. в Symfony есть Контекст безопасности и Брандмауэр.
Т.е. для авторизации на типичных сайтах характерно следующее: аутентификация - ввод пользователем логина и пароля, их проверка системой и если они совпадают с данными на сервере, то далее следует идентификация (поиск id пользователя) и авторизация (доступ к ограниченным ресурсам на основании id пользователя). Правильно ли я понял разницу между данными терминами?
Благодарю за данную тему. Новичкам вроде меня - очень пригодится. До данной темы не понимал большой разницы в представленных терминах.
Все просто - залогинился и система тебя признала - это аутентификация. Видишь у себя модераторские кнопки? Нет. А я у себя вижу. Это уже авторизация. Код форума для всех един. И часть кода, отображающая модераторские кнопки, отрабатывает и для тебя. Но отрабатывает иначе, потому что ты не проходишь авторизацию в ней. Зато проходишь авторизацию, дающую тебе возможность писать на форуме посты, к примеру. А вот гость ее не может пройти. И так далее и тому подобное. З.Ы. Авторизация возможна и без аутентификации. Например, гость авторизован смотреть посты в режиме readOnly. Но он явно не аутентифицирован на форуме. Хотя не исключено, что происходит неявная аутентификация как гостя. Но это уже вопрос конечной реализации.
Посмотри его сообщения. Это либо бот, либо очередной пользователь, считающий, что набитые сообщения дадут профиты. Я послал ему личку, чтобы подтвердить, что он не бот. Но его уже более суток не было на сайте.
Эмм если права в БД назначены админские, то выводить админские инструменты в скрипте комментариев(к примеру), если admin=0 - не выводить админ инструменты. ACL погуглю. А зачем использовать куки если в теле самой страницы comment.php(к примеру) можно сделать проверку на админ 0/1? проходит "авторизация" для меня как админ=0, а для вас как админ=1. Но мне кажется, мой вариант что я описал выше неверный как минимум в плане оптимизации. Должна быть единая проверка на права(наверно), а не в каждой части скрипта(комментарии, добавить новость, редактирование и т.д. к примеру). Где можно почитать о правильном методе? Просто хочу написать мини CMS под свои нужды(учусь) сперва на процедурном варианте и чуть позже на ООП, но не хочется изначально делать нубские ошибки на процедурном. П.С. Я старую тему поднимаю не для набития постов. Думаю в 2017 году этим уже никто не занимается. Просто хочу изучить теорию, чтобы не писать тонны кода которые позже посчитаю мусором. Это конечно хорошо для практики, но мне не 20 и тонны времени нет.
Не знаю, зачем использовать куки в данном случае. И не использую. И вам не советую. Права доступа - это такая штука, которую надо хранить на сервере. Клиент не должен говорить серверу, какими правами его наделять. Клиент вообще ничего не должен знать о своих правах - это не его дело. Работа клиента - ответ сервера принять. И запрос серверу послать. Точка. А админ это, или гость, или еще кто - сервер сам должен разбираться, без подсказок извне. Неверно. Ты пока что мыслишь категорией "админ-гость", "1-0". Но в реальном мире права не бинарные. Гость имеет право смотреть посты, но не имеет права их писать. Пользователь имеет право писать. Модератор имеет право все править. Администратор имеет право делать все на свете. Администратор может назначать других модераторов, а модератор не может. Но, если выдать модератору права, но супермодератор может назначать других модераторов. И тд. При этом, каждая отдельно взятая роль - не монолитная единица. Ты задолбаешься плодить проверки на гостя, пользователя, модератора, супермодератора, администратора, менеджера, техника, ограниченного пользователя и тд. И в какой-то момент запутаешься в этом всем и выйдешь в окно, потому что надо будет еще и самому помнить, кому чего можно. Попытка расширения такой системы будет вызывать страдания и каскадные правки. По-хорошему, каждая отдельно взятая роль - это пакет атомарных прав. Хочешь расширить полномочия роли? Докинь ей в этот пакет нужные права. И все. И ничего не нужно нигде переписывать. Нигде не нужно ничего помнить. Просто проверяй наличие конкретного атомарного права в том месте, где это необходимо. У меня сейчас своя платформа есть, самопильная. Система прав там реализована как раз именно так. Система люто-бешено модульная. Каждый модуль, при установке, может импортировать в ACL свой набор правил, которым пользуется. Модули, работающие комплексно, в рамках одного пакета, и имеющие идентичный набор правил, автоматически становятся совместимы между собой. При этом самой системе совершенно плевать на это все. Она знает только одну роль - суперадминистратора. Если такие права есть у пользователя, он автоматом проходит любую проверку. На все остальные роли ей побоку. Ее задача - проверить, есть ли у пользователя в пакете прав конкретная запись. А что эта запись означает, для чего используется - плевать. Это уже определяется контекстом использования. А с "единой проверкой на права" ты каши не сваришь. Делать отдельный вариант сайта для каждой роли чтоли?
еще не загуглил все что написали и сходу концепцию не представляю. но я имел ввиду что-то вроде этого: например в форме комментария этого форума по умолчанию видно все публичное: пожаловатся, лайк, цитата и т.д. но в теле скрипта есть строки которые проверяют аккаунт пользователя на наличие admin/smoder/moder = 1 {показ модер кнопок соответсвующих статусу пользователя}. не факт что конструкция if(){}, просто я ее первой освоил, потому-что был знаком с ней еще в паскале. и описанный мною метод - НЕ "единая проверка на права" . Т.е. в каждой области скрипта будь, то просто сайт с новостной или форум или гостевая есть строки проверяющие пользователя на админ права. И мне кажется что этот метод хоть и рабочий - делают так нубы. Поэтому думаю что есть более практичный вариант проверки прав. Просто это самое первое что приходит в голову, значит есть более удобные варианты.
Вот что я тебе скажу - если ты только только осваиваешься, то рано тебе лезть в дебри распределения доступа. Потому что это дело напрямую связано с умением строить архитектуру. А чтобы ее строить, нужно понимать глобально, как работает приложение, думать масштабно. А чтобы это делать, нужен опыт. А опыта у тебя пока нет и, как следствие: Это при том, что описанное мною - довольно простая система. Не беги впереди паровоза, осваивайся, учись. Начинай с простых вещей. Сложные придут сами со временем. Пока что тебе реально хватит is_admin();
Понимаю ACL, но в большинстве случаев и мне хватает is_admin() в реальных проектах. Полноценная ACL - это для достаточно крупного проекта, где типов пользователей потенциально дохрена, или админ может давать пользователям права произвольно
Именно так. Вот по этому автору это и не нужно еще. Разделяемые права, более 2-3 ролей, это вот все про сложные многопользовательские сервисы. 95% проектов "под ключ", не на готовых друпалах и пхпббхах в интернетах таковыми не являются. Что ты сам, собсна, своими же словами подтвердил
Я сейчас занят переделкой движка игры. Судя по коду автор писал этот движок на протяжении 5 лет и в разное время он имел разный опыт и знания. Пример отсутствия педантичности. Вообщем загнал я себя в дебри которые мне на данный момент не нужны. Скоро начну писать на процедурном, выкладывая весь код сюда, в отдельную тему. Проблема пхп для новичка в том что очень важен не только результат, но и, то как ты к нему пришел. Сейчас не 95-ый год. Таже авторизация делается проторенной дорожкой, есть стандарты которые загоняют новичка в рамки. Писать один и тот же результат 10-ю разными способоми не хочу. Нужно научится кошерно написать сайтик на процедурном, ооп и фреймворком. На Си мой быдло код в 10к строк даст тот же результат что и код в 2к строк. Там важен результат, а разница в быстродействии в 10мс с нынешними мощностями не имеет значения.