Блин, вот не понимаю я товарищей, которые используют шаблонизаторы всякие там смарти твиги или ещё хуже пишут свои шаблонизаторы.
Зачем, вам, может, понадобиться, шаблонизатор? Что бы верстальщику было проще? (Встречал такое мнение, поржал. С квадратными скобками ему же проще)
Что мешает сразу использовать родной if не оборачивая его в какие то непонятно зачем квадратные скобки а потом ещё и придумывать как запрограммировать парсинг своего никому ненужного синтаксиса да ещё и отлаживать это дело. Даже думать не начну над поставленным вопросом.
P.S: в тему пришел не поворчать, а подсказать, что вы занимаетесь бесполезным делом.
Ну каждый проектирует по своему...
Если тебе например захочется реализовать EDA архитектуру, то вызов слушателей будет контролировать какой нибудь менеджер событий и ты снова окажешься в ситуации как с array_map. Можно будет конечно передавать данные через объект события, но это не всегда может быть приемлемо и корректно.
Замыкания не есть "не нужный" механизм.
Часто он полезен в тех случаях, когда клиентский код не управляет вызовом колбека.
Как пример - встроенная функция array_map. В этом случае PHP сам решает с какими аргументами вызвать функцию обратного вызова и мы не можем передать дополнительные аргументы этой функции когда это требуется.
Тут на помощь приходит механизм замыкания, который позволяет решить данную проблему. Технически этого можно добиться использованием глобальных переменных, но в чем их беда, в этом топике думаю все знают.
Подобные ситуации не ограничиваются некоторыми встроенными функциями PHP.
назовите хотя бы одно преимущество создания объекта класс stdClass перед созданием обычного массива
Массив и объект это разные типы данных, каждый из которых имеет свое поведение и область применения. Исходя из этого можно сделать вывод, что ваш вопрос некорректный. Массив не является заменой объекту-пустышке, точно так же, объект-пустышка не является заменой массиву.
В зависимости от ситуации может быть удобно работать как и с stdclass, так и с массивом. Просто нужно понимать, что в случае необходимости изменять данные по ссылке внутри простого контейнера, через объект-пустышку это будет сделать удобнее. В случае же с массивом, придется извращаться с явными ссылками.
Если же есть сложная структура данных, возможно требующая дополнительную обработку, то массив самое оно, ну или ArrayObject/ArrayAccess например. Вообщем, хорошо освойте что из себя представляют объекты и массивы и выбирайте тот или иной инструмент когда на ваш взгляд он подходит лучше.
Если пользователь лопух и у него стырили логины и пароли, или как то вошли на его мыло, после того как он решил менять пароль за чужим пк, или же не нажал кнопочку выйти, когда находился не дома, то в чем тут, может быть вина разработчика?
Вы серьезно думаете, что все пользователи имеют хотя бы минимальное представление о политике безопасности? Открою страшную тайну, нифига подобного! Понятное дело что человек может отойти/уйти даже с открытым аккаунтом на вашем сайте и его могут грохнуть. Но есть варианты. Сайт может быть закрыт, а почта открыта. Ещё раз, не все имеют хотя бы минимальное представление о безопасности и не всегда и не все пользуются компьютерами в надежной среде. У некоторых может вообще дома не быть компа/интернета/провайдер сломался
И задача разработчика не всегда заканчивается на серверном уровне. Бывает так что нужно думать не скриптами а чисто логически, как сейчас например. Если юзер разбрасывается паролями то да, от небрежных мы не застрахованы. Но нужно ещё учитывать человеческий фактор. Или вы ещё и думаете, что все люди идеальны?
Не нужно все спускать на тупость пользователя там где мы как разработчики можем решить некоторые проблемы. Так почему не сделать это? Для продвинутых пользователей - да, как уже говорил, можно дать выбор в том случае, если выбор между удобством и безопасностью колеблется. Но по дефолту ставить высокий уровень защиты. Неужели сложно сделать вывод, что нельзя отправлять на почту информацию о доступах к другим ресурсам? Даже если доступ временный!(Утверждение касается того случая, когда есть регистрация на сайте). Когда аккаунты незрелых пользователей нагнут, знаете что они будут говорить? "У сайта ввв.сайт.ру хреновая защита! Меня взломали! Не пользуйтесь этим сервисом!".
Я тут ещё раз подумал над этим вопросом, появились новые мысли с которыми хочу поделиться.
alnik-75 пишет:
Тогда как, в свете этих проблем, решить вопрос о восстановлении забытого пароля, когда с сайта по почте приходит вновь сгенерированный и измененный в БД для конкретного пользователя пароль?
Думаю не следует менять пароль самостоятельно и отправлять его на почту по следующим причинам:
1. Зная e-mail можно доставлять пользователю неудобства, высылая пароль(если для восстановления достаточно указать e-mail адрес)
2. Пароль может остаться у пользователя на почте и при получении доступа к почте злоумышленник может воспользоваться паролем, если юзер его не сменил. В инет кафешках обычно установлены программы, которые блокируют компьютер когда у клиента закончилось время и очень часто клиент просто уходит. Вместо него может сразу сесть за комп новый клиент, и если админ не перезагрузит машину/не закроет все открытое, новый клиент окажется в почте старого клиента.
Посему. Лучше отправлять на почту специальный код(с малым сроком жизни), после ввода которого пользователь мог бы установить новый пароль самостоятельно на сайте.
Мелкий пишет:
если есть доступ к почте, то восстановить пароль учётки на сайте штатным средством через эту же почту проблемой не является.
При более хитром подходе, это будет проблематично для злоумышленника. Вариант со второй почтой конечно же неплох, но все же пересмотрел свое решение в пользу установки секретного вопроса. В этом случае, даже имея доступ к почте, какер не будет знать ответа, и доступ к почте так же ничего не даст.
Что касается ссылок со сквозным входом, приведу аналогию в спойлере.
Одно время мы с другом зависали в вап чатике, где логин и пароль передавался GET-ом, был всегда в ссылке. Так вот, общаюсь я с ним, и вдруг замечаю что ведет он себя как то странно. Как выяснилось позже, он в общий чат случайно отправил содержимое адресной строки. Следующие 10 минут я общался со злоумышленником. Попросил бы он меня о чем то без лишних слов, я бы наверное не отказал. То же самое может случиться и с отправленной на почту ссылкой для входа.
если есть доступ к почте, то восстановить пароль учётки на сайте штатным средством через эту же почту проблемой не является
Да, но в случае если привязать аккаунт к мобильному телефону то доступ к почте ничего не даст. Ну или сделать 2 почты, одну приватную, другую для рассылки, но что бы юзер сам выбирал, использовать одну почту или две. А когда будет скандал, проект окажется прав ибо предупредил о возможных вариантах и чем это может обернуться... выбрал одну почту - сам виноват...
Я думаю задача серьезного проекта обеспечить максимальную безопасность со своей стороны относительно важных данных и зон доступа в приложении. Если есть варианты выбора между удобностью и безопасностью, то этот выбор, как правило, предоставляется самому пользователю, а не рубится по желанию разработчика.
Что бы был раздел типа "Предупреждение о безопасности" и там написать, уважаемый юзер, вот тебе несколько вариантов, хочешь сквозной вход, можешь нажить приключение на одно место по таким то причинам, но будет удобнее. Не хочешь сквозной вход, отметь чекбокс и спать будешь спокойнее, но вводить пароль придется всегда.
Что еще можно сделать, чтобы при таких невыгоднях условиях максимально обеспечить безопасность?
Для рассылки ставить время жизни было бы не очень корректно. Это событие не имитируется самим пользователем и он не знает когда придет сообщение от вас. Придет оно утром, а юзер вечером после работы перейдет по ссылке но хеш уже устареет. А ставить длительный таймаут тоже не вариант(Мы не значем как часто юзер проверяет почту). То что я говорил про таймауты это был ответ на ваш вопрос по поводу восстановления пароля.
alnik-75 пишет:
Что еще можно сделать, чтобы при таких невыгоднях условиях максимально обеспечить безопасность?
Не отправлять ссылки, способствующие сквозному входу. На том же фейсбуке, у которого много пользователей по всей планете при рассылке из почты нельзя прямо попасть в аккаунт. Миллионы пользуются и все нормально.
Если вам нужно сообщить пользователю какую то заманчивую информацию, то отправьте её по почте обычным текстом. В случае если юзеру надо что то сделать в личном кабинете, написать об этом в письме, а там он сам решит, зайти ему в систему, делать это действие или не делать...
Если безопасность критична, то привязывать управление подобными операциями к мобильному телефону и желательно со сроком жизни. К примеру если в течении 5-15 минут не будет введен код, то он устаревает. Или через e-mail(если подобная безопасность менее критична), но тоже со сроком жизни. Как видите правила ужесточились, но от дебилов, обычно, никто не застрахован. Можно ещё больше ужесточить подобные процессы, все зависит от критичности и почти всегда есть свои плюсы и минусы.
А не обязательно что бы злоумышленник сам перевел деньги. Он может со своего аккаунта написать другу Васе, который не подозревает о взломе, что бы Вася перевел деньги на определенный счет. А Вася поверит, потому что это ему Петя написал, его лучший друг!
Можете отправлять ссылки для сквозного входа, вам никто не запрещает, но минусы как бы я вам сказал (Добавление)
alnik-75 пишет:
Такой вариант приемлем?
Я об этом именно и писал Только не хеш таблицу а достаточно было бы в таблице с юзерами сделать дополнительное поле типа force_auth_hash. Но чем плох этот вариант тоже написал
Вообще идея не очень хорошая, объясню почему так думаю.
Основная проблема как вы заметили заключается именно в безопасности. Генерировать ссылку на основе банальных данных типа id не следует, ибо легко подобрать. Можно усложнить подбор генерируя одноразовый рандомный и сложный хеш для входа при отправке рассылки, но у этого способа тоже есть свои недостатки. Пользователь может отойти от компьютера в момент получения письма и кто то сторонний просто начнет шариться у него в почте и наткнется на ссылку. Или юзер случайно скопирует куда-то в чат ссылку и отвлечется сразу же например на звонок. Пока он будет говорить по телефону аккаунт уже 100 раз успеют нагнуть Или юзер тупо может уйти забыв нажать кнопку "Выход" из почты, а через 10 минут вы отправите ему письмо. Соответственно доступ может оказаться у кого угодно. Не все сидят из дома и с запароленным входом на десктоп.
Как правило вход в систему должен быть явным, с указанием логина и пароля(это вовсе не значит, что логин и пароль нужно отправлять в ссылке. см.выше).
Заставляйте вводить данные без готовых ссылок. А после правильного ввода данных можно показать запрошенную страницу.
Ничего страшного в этом нет. Удобство удобством, но безопасность важнее. Особенно если в проекте есть денежные операции. Я бы не стал тратить деньги в проекте который присылает мне на почту ссылки со сквозным входом в систему.
Какой помощи? Выше написали строчки которые сохраняют данные.
Если создается картинка с адресом где указана сессионная кука и элемент картинки есть в DOM, а так же есть доступ к кукам через javascript, то все должно быть в порядке.
Чем ещё помочь, я не знаю. Может у вас вообще веб-сервер не запущен, я откуда знаю то.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1465
Только не хеш таблицу а достаточно было бы в таблице с юзерами сделать дополнительное поле типа force_auth_hash. Но чем плох этот вариант тоже написал
