ну вот если я решу взломать юзера MAXUS к примеру)))) я ж могу зайти в любую тему и увидеть его логин в коментах к постам))
Я ж не знаю, какая у тебя конкретная задача. В отношении форума, согласен, не особо поможет, но в отношении какого-нибудь сервиса усложнит. А регистрозависимый пароль - это обязательно, кмк. Хотя... по большому счету тоже зависит от задачи. Ты просто про фэншуй спрашивал. Как сказал один пожарник, по фэншую вместо экибаны тут должен быть огнетушитель
Alessanderrr пишет:
Хотя, мне сейчас пришло в голову: данная проблема упраздняется в случае, если при регистрации обязательно указание email.
Если используешь e-mail, то обязательно организуй подтверждение через отправку письма. И принимай во внимание, что в email регистр не играет роли.
Alessanderrr пишет:
А вот это очень прикольно)) можно примерчик, как это добро реализовать?
Нене... Опытом поделиться или что-то для себя интересное подчерпнуть - это завсегда. А напишите за меня пожалуйста - это, прости, но лень. В общих чертах - меняешь все спорные символы на определенный символ латиницы, таким образом формируешь хэш. Например, ноль на O, при этом переводишь или в нижний или в верхний регистр (как удобно). При проверке на существование сравниваешь с ним, а не с логином.
Народ. Вот такая делема. Пытаюсь создать каталог товаров, прочитал про Neither Sets. Приблизительно понял в чём суть, но не могу найти в примерах пошаговую реализацию этого чуда.
А нельзя уточнить, что такое Neither Sets? Любопытно...
А по поводу шаблонов... Это как в литературе, музыке и кино. Нет чистых жанров. Есть жанровые признаки. Чистый жанр бывает только в начале его образования, а далее как правило идет смешение в зависимости от творческой задачи. С шаблонами, кмк, точно также.
Таки, прошу объяснить, зачем должен иметь значение регистр логина при авторизации? Не с целью поперепираться, но с целью понять как правильно и почему
Количество комбинаций возрастает в разы, таким образом усложняется подбор. Обрати внимание на сообщения о степени защищенности пароля в банковских системах, например, да в тех же cms.
Alessanderrr пишет:
Если я правильно понял вышенаписанное, то моя первая проверка отсекает возможность написание чего-либо кириллицей... Не?
если нет, то можно примерчик как правильно?
Отсекает. Но не отсекает первый пример, где вместо O используется ноль. Про кириллицу просто для примера сказал. В моей практике был миллион случаев, когда, например, на форумах тролли регистрировали похожие на нормальных пользователей имена и писали от их имени всякую хрень. Модераторов иногда это ставило в конкретный тупик
Таки да, проверка должна быть регистронезависимой, и я на пальцах понял как это сделать, но вопрос был не в том, делать ли или нет, а как именно сделать)
Собственно, решение видится так:
При сравнении существует ли такой юзер, значение из базы и значение из введенной формы приравнивается к одинаковому регистру, и таким образом дубль юзера создать не даст.
Да. Я бы еще проверял на совпадение TOMAS и T0MAS. А при использовании кириллицы ТОМАS и TOMAS... Т.е. приводил к одному хэшу из латиницы.
Alessanderrr пишет:
Так же и при авторизации - сначала значения приводятся к единому регистру, а уже затем сравниваются, и если совпадают, то проверка выполняется успешно.
Сначала написал свое решение потом до конца сообщение написал, мы одно и то же написали)))
При авторизации регистр должен иметь значение.
Alessanderrr пишет:
Но главная беда моего поста в том, что у меня процесс встал на проверке наличия такого же юзера в базе - что бы я ни ввел (при условии выполнения условий допустимости символов и длины логина) я в любом случае получаю сообщение о том что такой юзер уже существует. Косяк гдета должен быть элементарный но найти его чета у меня не получается, вот и прошу помощи!
Тебе же написали, что проверка на существование у тебя составлена не правильно. Всегда возвращает true.
можно было бы такое замутить, но переписывать дофига, и не знаю зачем, но вдруг в каком то из методов исходного класса понадобится получать кешированное значение
Иначе говоря шаблон registry. Но перед этим определиться зачем...
(Добавление)
DelphinPRO пишет:
через магию __get ?
Тока учесть, что __get вызывается при обращении к недоступным свойствам. Т.е. если какое-то свойство определить, то он уже не сработает.
1) Как сделать (по феншую) проверку логина и авторизацию регистронезависимой?
В моем представлении по феншую проверка логина и пароля должна быть как раз регистрозависимой.
Другой вопрос - это желание избежать дублирования имен типа Vasya и vaSya, но это к проверке не относится. В этом случае при проверке существования при регистрации приводить передаваемое и получаемое значения к одному регистру.
Прошу Вас ознакомиться с созданной мною темой и дать советы по ее реализации.
Помогите правильно реализовать авторизацию, например, из письма почтовой рассылке, где имеется ссылка на личный профиль (кабинет пользователя). Понятно, что в ссылке из данного письма можно указать GET-параметры с данными пользователя (например, его id) и при переходе на сайт из базы получить данные по id этого пользователя и авторизовать его "принудительно", т.е. без введения всей необходимой информации. Данный способ совсем мне не кажется безопасным, в связи с чем я и создал эту темы.
ПРОШУ Вашего содействия в этом вопросе.
Заранее благодарен, Александр
Почитал мнения. Вопрос свелся к соотношению удобства и безопасности.
Из личного опыта. "Сквозная" авторизация само по себе не плохо и удобно. Вопрос в том насколько однозначно определяется пользователь. В предлагаемом варианте идентификация производится по электронному адресу, т.е. подразумевается, что если пользователь получил письмо, то он уже может быть однозначно определен. Т.е. условно доступ открывается "предъявителю сего". Т.е. у кого письмо, тот и получит доступ.
Уже из предыдущих двух фраз становится понятно, что это не самый лучший уровень доверия. Например, корпоративная почта контролируется админом. В моей практике была масса случаев, когда админ лезет в чужую почту по своей инициативе или по заданию руководства. Причем как в момент, когда владелец ящика еще работает, так и через полгода после его увольнения. Соответственно, даже на этом примере видим, что этот метод авторизации череповат боком.
Рассуждаем далее. Но ведь используют! Подтверждение при регистрации, восстановление пароля! Да. Но с определенными ограничениями. Во-первых, жизнь таких ссылок ОБЯЗАТЕЛЬНО должна быть ограничена по времени существования. В случае подтверждения при авторизации от минут 15 до суток, например, но не более. В случае восстановления пароля еще и дополнительно нужно требовать секретное слово типа девичья фамилия матери и т.п. В противном случае такие ссылки станут дырами и рано или поздно кто-нибудь этим воспользуется.
Вообще, если вернуться к соотношению удобства и безопасности, то надо все-таки отдавать себе отчет, что способ определения пользователя по электронному адресу - не надежный, поэтому с его помощью открывать доступ с целью обеспечения удобства можно, но далеко не ко всем разделам сайта. Например, к какой-нибудь голосовалке - пожалуйста, при этом голосование пройдет от имени пользователя, определенного по электронной почте. Но авторизовать пользователя только по одному e-mail - это риск. Авторизовать, т.е. предоставить доступ ко всем разделам, требующим авторизации. Соответственно, доступ к личному кабинету предоставлять таким образом нельзя ни в коем случае, т.к. за этим тянется возможность изменить личную информацию, написать от имени пользователя какую-нибудь фигню и еще бог знает что в зависимости от возможностей системы.
Есть вариант ввести при авторизации чекбокс "запомнить меня" и, если пользователь авторизуется с установленным чекбоксом, то создается хэш, который пишется в базу и соотносится с пользователем, а также пишется ему в кукисы. Также необходимо установить срок жизни такого хэша (как в кукисах, так и в базе). В данном случае, если пользователь авторизован и "запомнен", то перейдя по ссылки из письма, ему просто не потребуется авторизоваться. А если не авторизован, то уж извините, хотя бы один раз в месяц, но это сделать надо
Да прочитал, в принципе Инкапсуляция - механизм, который позволяет объединить внутри объекта данные и связанные с ними функции, закрыв их от прямого внешнего изменения. Private переменные, как составляющая инкапсуляции отвечает непосредственно задаче закрыть возможность прямого доступа извне, но не отвечает задаче скрыть данные, которые а них хранятся, а попросту в большинстве языков они доступны для чтения тем или иным способом.
Поэтому вывод 1. Нефиг хранить в них то, к чему ты хочешь ограничить доступ не только на изменение, но и на чтение. Следует иметь в виду, что объявив внутри класса переменную как private вы не только предоставляете возможность другим функциям класса читать и изменять данные, но и предоставляете к таким данным доступ на чтение извне.
Вывод 2. Вернее предположение. Переменные не будут видны извне:
- только внутри scope функции (традиционно)
- или если они объявлены внутри класса как private static (вот это как раз предположение), я во всяком случае не нашел способа к таким переменным продолбиться. Например,
Если есть способ считать $v1, то подскажите, чтобы я не заблуждался (Добавление)
Мелкий пишет:
Ну вы бы ещё про сериализацию вспомнили. Там можно даже менять приватные переменные, не то что читать из значения.
А уж про возможность менять приватные члены в рантайме тупым closure::bindto я даже не говорю.
Если человек захочет сделать глупость - он её сделает. Поэтому не занимайтесь борьбой с ветряными мельницами. Если хочется влезть в потроха - это сделают.
Правильно я понимаю, что при помощи Closure::bind можно и статические переменные считать? Просто у меня php 5.3...
Ну, и вопрос просто логики. Для чего нужны private переменные? В чем их суть?
Вот с этого стоило начинать.
Что бы это понять, нужно полнимать ООП, и в первую очередь - инкапсуляцию.
Можно начать с википедии https://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
По-моему, вопрос как раз вызван тем, что подобное поведение противоречит принципам инкапсуляции:
Encapsulation can be used to hide data member and member function. Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition.
Ну вы бы ещё про сериализацию вспомнили. Там можно даже менять приватные переменные, не то что читать из значения.
А уж про возможность менять приватные члены в рантайме тупым closure::bindto я даже не говорю.
Если человек захочет сделать глупость - он её сделает. Поэтому не занимайтесь борьбой с ветряными мельницами. Если хочется влезть в потроха - это сделают.
Не. Это не борьба с мельницами. Я как раз спросил, чтобы понять - это мельница или нет?
Ну, и вопрос просто логики. Для чего нужны private переменные? В чем их суть? (Добавление)
Мелкий пишет:
Ну вы бы ещё про сериализацию вспомнили. Там можно даже менять приватные переменные, не то что читать из значения.
А уж про возможность менять приватные члены в рантайме тупым closure::bindto я даже не говорю.
Если человек захочет сделать глупость - он её сделает. Поэтому не занимайтесь борьбой с ветряными мельницами. Если хочется влезть в потроха - это сделают.
А static переменные можно каким-то способом считать?
Я давно заметил, что у части разработчиков с опытом развивается самокритика.
Но это не ответ на вопрос. Это даже не попытка... Потому что вопрос ты не понял. Ты можешь с помощью var_dump или print_r прочитать код?
Вопрос в том, зачем создавать private переменные, если их можно считать? Функцию ты не запустишь, а переменные - пожалуйста, вот они. В чем тогда смысл делать их приватными? Для чего разработчики php делили переменные на public, protected и private? Только, чтобы их нельзя было изменить?
Получается, что как только ты делаешь переменную доступной для всех функций внутри класса, она сразу становится доступной для чтения извне. Я нахожу это глупостью, если не предусмотрен механизм такое поведение изменить. Я понимаю, что для отладки это удобно, но в дальнейшем это превращается в косяк. С моей точки зрения...
А есть ли способ закрыть возможность вывода приватных переменных объекта через print_r(), да и var_dump() и любым другим способом тоже?
Ну, т.е. не хочу, чтобы закрытые переменные класса можно было считать таким способом. __set_state(), __debugInfo() знаю. __debugInfo() только начиная с 5.6 работает. К тому же вряд ли она закроет print_r().
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 329
