недопустимы потому, что указан в качестве примера был пароль содержащий символы "><", я как разработчик продукта посчитал эти символа, как и любый html теги недопустимыми к использованию, жизнь не справедлива, не более. вот пример валидного везде пароля "pDS@FcV6wHj8n5e". И да я не слышал о том, что кто то разрешает использование этих "треугольных скобок" или других хтмл в пароле. Безопастность - согласен варриант sql инъекции есть, но надеюсь не слишком сложно предположить, что меня это устраивает и наверно можно понять, что о prepare я слышал, раз уж использую пдо Просто каюсь, отнесся не серьезно и удалил все "приготовилки". strip_tags(htmlspecialchars(trim($value))), гуглом я не пользовался и Попова не знаю. Я вроде пояснил зачем искал в доках эти функции... удалить проблеы (они мне не нужны), преобразовать все символы, которые возможно в хтмл и удалить их. Мне этих проверок показалось достаточно, если речь опять таки о инъекциях, тут я согласен и не спорю. Меня смутило только это: и потому я попытался пояснить, что кое -что у меня за спиной есть и потому в некоторых вещах я уверен. В частности проблем с логикой я не вижу, как и проблем с архитектурой и использованием ресурсов сервера. Или стоит повторить, что указанное место с лишним запросом к бд лишенно такового, а куки используются не только для счетчика, но и для хранения данных пользователя и счетчик обнулить нормальному человеку не получится, поскольку их очистка вынудин залогиниться повторно. Безопастности нет в использовании куков вместо сессии? ну как бы опять так согласен, не серьезно отнесся к реализации и ожиданиям заказчика. Ошибку признаю, но все перечисленное вами мне более чем знакомо и причины этого не в не понимании. Скажем так, тут я не расстроюсь, поскольку это осознаю и ожидал. По поводу архитектуры, еще раз я осознанно использовал такю структуру классов именно потому, что я могу дописать логику работы с бд и включить дополнительные функции для работы с другими источниками, добавить в "воркер" валидатор как зависимость не переписывая ничего и это сокроет лишние функции от пользователя кода, которому кроме воркера ничего не нужно(т.е. лезть в класс работы с базой, валидатор и т.д.) + это дает тестируемость и в данном случае тестируется легко, что изначально предусмотренно, но опять таки не реализованно в виду не серьезности отношения (да ошибочного это я признаю в очередной раз). Ровно как и фабрика созданна для упрощения логики в handler и опять таки тестирование кода, этот класс для меня его упрощает в разы. Да объект Юзер ожидает проверку того же параметра, согласен лоханулся, в момент рефакторинга, после добавления фабрики упустил это. Но опять таки, каюсь торопился, кино смотрел... не оправдываюсь, признаю О опыте я сказал потому, что во первых я не первый раз пишу код и работал с приложениями в команде с несколькими десятками таких же, как я. У меня нет практически коммерческого опыта работы с базами и пхп в целом, мой мир -это клиент и handhandled systems. Скажем так такую "избыточную" архитектуру я выбрал осознанно потому, что не вижу избыточность, а вижу легкость и простоту в поддержке. Собственно что не понравилось, попытка дать оценку тому, как я 10 лет говнокодил.. Отсутсвие примера эталонной реализации и в большей части критика по поводу "вкусовых" пристрастий критикующего и автора. Думаю достаточно будет сказать то, что на сегодня разработка приносит мне денег больше чем предложенно в списке вакансий (дальше первой странице не просматривал) тут примерно в два раза... но это ведь не имеет значения? хотя да говнокод чсв задевает ))) но это скорее тролинг и к сути не относится )) В целом я согласен и слов о том, как все хорошо не ждал, но меня интересовало мнение с точки зрения того, как это делается в php. Что касается хранения сессий и т.д. Задачи сделать код безопастным небыло, моя задача вообще была - пройти по пунктам максимально быстро. Если речь о том, что этот проект должен быть передан заказчику я бы его не принял, для меня требования без js звучит "тут не хорошее слово, матюкаться не буду...". Если не сложно заметить никаких "готовых" решения я не использовал, что считаю в реальной работе глупостью и подразумевал, что если есть pdo и данные в куках сериализовались, как и логин пользователя сохранение счетчика доступо для клиента, то понятно, что изменить это на сессии и т.д. будет не сложно. Я бы вообще предпочел jwt и никаких сессий, а счетчик по прежнему в куках, мне никто по прежнему не докажет, что я делаю плохо устанавливая его при логине Потому эта реализация -игрушка написанная за пару часов на инструменте про который я вспомнил 4-5 дней назад. Для вас это говнокод, для меня достижение, поскольку я смог организовать этот код в чужой для меня среде и заставить его работать, по поводу архитектурных решений, в них я уверен, в том, что реализованно через жопу.. ну как бы поспешишь... согласен. И критика с точки зрения продукта отданного заказчику для меня несколько дико звучит p.s. если что то звучит сумбурно и незаконченно, прошу прощения, перечитывать времени нет, пишу и переодически отвлекаюсь, надеюсь основную мысль донес, и никого обижать не хотел. За ревью благодарен, а то, чт оспорю... ну так бывает, встречаются такие идиоты, как я которые не умеют молчать ))) Добра вам в общем Попробуйте представить, что этот код писал человек который потратил примерно 3-4 месяца на изучение пхп несколько лет назад читая мануал, внес правки в проект заказчика и забыл про него... и меньше недели, как снова взял его в руки до этого вообще не имея дел с разработкой на стороне сервера, при этом этот человек программист работавший в "долине" и дошедший в рейтах до $65. Меня никто не учил этому и каждое решение, которое вы тут видите, даже то, что используются урлы "?login&something" - мое личное изобретение сделанное вчера, когда увидел и обдумал задачу.... я в буквальном смысле не читал не только ваши комментарии к предыдущим исполнителям, но и понятия не имею, как это решать принято... мои знания - чтение документации, языковых конструкций и списка функций... все остальное -общая информация из личного опыта.... а самоуверенность губит... представьте, что о работе я спрашивал поскольку, это критерий оценки, а не потому, что я ее ищу... мой опыт говорит - самоувернность открывает двери.
Но почему? "Потому что" - так себе ответ. Все, что я силюсь понять - логику этих ограничений. Это же иррационально. Разработчику все равно, серверу все равно. Практической пользы нет, экономии времени нет, упрощения поддержки нет, есть только неудобства пользователя. Просто задумайся об этом. Ограничение ради ограничения. Без смысла и выгоды. Зачем? Я так в свое время полностью от алкоголя отказался, просто спросив себя "зачем?" и не найдя ни одного рационального ответа, не входящего в список клишированных отговорок. Это, в общем-то подразумевается само собой и "заказчик" об этом даже не дожен думать. Заказчик просит сайт. Он понятия не имеет о инъекциях и тд. Об этом должен заботиться исполнитель, такая вот тут мораль. Ты все же чуть обиделся. Тут все просто, гляди, ревью делается вообще без учета способностей, знаний и опыта исполнителя. Это интернет. Мы друг другу только ники и аватарки. Все, что мы говорим о себе другим не имеет значения. Я делаю ревью, просто как есть, ставя перед фактом. Если есть проблемы - я их обозначаю. Не важно, какова их причина - спешка, отсутствие опыта или пренебрежительное отношение. Я просто на них указываю, аргументируя это. Нет никакого смысла скрывать от кого-то что-то только потому, что "он еще недостаточно опытен в этом вопросе". Наоборот. Я был бы только рад, если бы у меня, в свое время, за спиной кто-то сидел и указывал на ошибки. Столько времени было бы сэкономлено...
ну и как же я забыл прокомментировать выражение "спагетти код", дело в том, что было бы интересно в каком месте? На сколько я помню методов однострочников там как раз быть не должно, в методы вынесенно только то, что используется повторно во избежании дублирования, что в книге "рефакторинг с использованием шаблонов" относится к признакам "плохо пахнущего" кода.... --- Добавлено --- все ок, это не обида, а скорее именно задетое чсв . По поводу символов в пароле, это скорее не "потому, что", а "так принято", фильтровать html элементы необходимо, поскольку это тоже уязвимость, пусть и не влияющая на фичи, но способная испортить верстку. Потому разрешать хтмл нельзя. По поводу же треугольных скобок, именно ввиду приведенного примера, фильтрация на хтмл может убить данные пользователя и это лучше исключить ужесточением требований. Очень высока вероятность непредсказуемости ввода вот и все. В теоррии можно их разрешить и имя пользователя вроде "<span style='color: tomato;'>Уася" отдавать как есть не давая браузеру на них реагировать, но зачем? просто так сложилось... а там же и джи эс может быть передан.... и в случае передачи в формате кодировки, функция преобразует это в хтмл, который другая может удалить... а остатки js после этого с пробелами и т.д. будут выглядеть просто сложным ником, если пробелы удалить Но опять же я предпочитаю валидацию на клиенте, да ее обойти проще, и опять таки я предпочитаю при отключении js отдавать упрощенную версию и регистрация там просто не будет возможна. Я вообще не верю давно в то, чт опроверки на клиенте легко обходятся, токены и хеши передавать туда сюда просто с каждый запросом, готовых и протестированных решений полно. Потому все относительно. p.s. это только у меня после редактирования сообщения дублируются? а после повторного дубликат удаляется.. но текст сохраняется в поле ввода нового сообщения
Путаешь понятия "одноразовый" и "однострочный". Вот мы к главному и подошли - вместо завандаливания воодимых данных, надо преобразовывать отображаемые. Просто фильтровать все, что выводится на страницу, но не должно интерпретироваться как html, оборачивая это в htmlspecialchars. И ник, например, в виде странного смайлика "<!>_<!>" будет отображен именно так. Даже если ником будет "<script>alert('XSS,BITCH!');</script>", это отобразится как простой текст. Вот и решение всех проблем, без ограничений и неудобств. Нет, это багофича форума. На деле дублирования не происходит. Обнови страницу и сообщение останется лишь одно.
Вообще пофиг, что в пароле. Он по любому хешируется - в хеше нет символов, которые могут испортить запрос. Путь юзверь хоть "Войну и мир" туда перепечатает, а хочет - скрипт уничтожения вражеской атомной электростанции. В логине ещё есть какой-то смысл вводить ограничения, но элементарное пропускание всех выводимых (не вводимых, а выводимых) данных через htmlspecialchars позволяет не заботится и о том, что у пользователя в логине
ок, согласен. Моя политика наличия символов в пароле и их отсутствия была слишком жестока и ограничивала свободу выбора пользователя и поскольку мы живем в демократическом обществе в предь обязуюсь разрешать символы - ` ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] \ | : ; " ' < > , . ? /
@applicab Надо вам батенька сессии осваивать, а то жуть че понаписано. А это вообще что и зачем? PHP: } else if(isset($_GET['registration'])) { // just show some message that can be returned echo $_GET['registration']; } else if(isset($_GET['error'])) { // show error messages that can be returned echo $_GET['error']; } А это что? PHP: if($_GET['login'] != ') --- Добавлено --- Выкини это из головы и перестать запрещать
с механизмом сессий я знаком и он меня не устраивает, предпочитаю работу на основе токенов и т.д. В данном случае это проверка возвращаемых значений, т.е. генерируемые события.. ошибка там или успешная регистрация, поскольку в задаче обработки такого небыло, делал просто по привычке и для удобства своего. Устанавливается в гет параметре поскольку эти параметры уже использовались а сессии я изначально не использовал просто потому, что сохранение этой самой сессии пользователя скорее демонстрировал, чем реализовывал решение, отсюда и куки... на практике я исключаю свое участие в задачах, где установленно требование нет джи эсу и авторизация на сессиях, как минимум jwt. Вывод оставил просто потому, что к примеру после регистрации возвращается форма логина или ошибки бывают разные, это сообщение покажет статус... все ок, или имя пользователя уже занято или просто ошибка ввода данных, например поля пусты... красиво показывать ошибки было лень, просто демонстрация того, что они не упущенны... да и че там осваивать то? сессион_старт, ДОЛЛАР_СЕССИОН[уаяся]=тут ты живешь ? ))) да и как по мне состоянии приложения нужно хранить в одном месте, у меня там объект воркер, так вот он по сути знать обязан залогинен пользователь или нет, все эти сохранения в куках -это скорее для удобства получения этих данных с клиента... а ну да клиента не используем... ну блин перемудрил я с тем, что ожидал, что можно и тем что в итоге сделал задумка была несколько полнее дедлайн подвел и имеем то, что имеем дедлайна небыло? нуу.. у меня был в общем там по задумке сессии совсем не нужны.
слыш! сессия и есть токен но я тебя понял --- Добавлено --- что? --- Добавлено --- сессии удобны. идея со стейтлес приложениями она прекрасна как рестлфул апи. только на практике это единорог который в вакууме.
в смысле я не хочу хранить сессии на сервере, мне буквально не нужно, чтобы сервер что -то знал о сеансе пользователя, это полностью задача клиента. Все, что должен сделать сервер отдать токен, остальное не его проблема.
теорию я знаю. я не знаю как сделать так, чтобы гронухть все сеансы и токены пользователя. чтобы обнулить их вот в этот вот момент. вот украли у юзера пароль и он его сменил и разлогинился везде-везде. Как ты можешь такую задачу решить чисто на токенах? =)
как бы в базе есть таблица в которой актуальные токены, там даже привязка прав доступа, права можно изменить на устаревшие и показать сообщение или отправить емелю (почта по нашему ), можно просто drop database, все от фантазии зависит. Можно кленту сообщить что токен не актуален и он перезапросит, варриантов масса... это стандартный путь, может потому, что с пхп я плохо знаком не знал, что сессии так популярны, но я давно не встречал их использования ))) сессия -это странно, зачем она мне если мне не интересно авторизован пользователь или нет, запросы фильтруются токеном, а остальное вопрос клиента.
а, ну можешь не продолжать, это привет состояние. это принципиально ничем не отличается от сессии. Это я и имел в виду.
в смысле не отличается ? это принципиально разные вещи просто потому, что задачи клиента и сервера разделены. Сессии нужны, но серверу знать об этом не нужно.. 2017 год.
ну так спешу тебя поздравить, старина, ты с ними работал непереставая! просто не знал об этом. То, что сессии по факту хранятся в бд и они вечные никак их принципиально не отличает от сессий пхп, которые могут жить "на файликах", в бд, в редисе, в мемкеше, апц и т.п.
здрасте приехали. Сессия это токен плюс данные которые к нему присобачены. Если ты говоришь о чистых токенах, где нет присобаченых данных, то да, это заебись. В теориии. А по факту ты говоришь, что ты решаешь вышеозначенный мною вопрос через хранение чего-то в бд. Т.е. это сессия и есть со всеми вытекающими. А нравится тебе это или нет - это второй вопрос. По факту ты не можешь токен заюзать напрямую, ты долежн слазить в хранилище и проверить, что там с этим токеном связано, валиден ли он, ни смотря на то, что он валиден по хешу. --- Добавлено --- у пхп есть четкая задача - сайтики. То, что на нём можно писать "приложения" это плюс, но сайтиковый функционал это не выпиливает. На сайтике сессия это манна небесная. Ты просто говоришь мол этот человек находится в визарде на шаге №3 и вот данные с предыдущих шагов. Всё. Ни бд не надо, ни умных токенов. Это та автоматическая часть, которой пхп хорош.
это конечно может показаться недостатком, но с точки зрения именно 2017 года и того на сколько изменился клиент и его задачи это дает возможность доступа клиенту этому к механизму сессии. Если же это делать чисто на сервере, то клиент ничего об этом не узнает, придется так же сохранить сессию в бд и т.д., в итоге те же яйца но больше шагов. Ровно как и сам процесс регистрации подразумевает получение токена и он же задействован в регулировке прав доступа, решается масса задач. но в целом в общем то да, спорить тут не о чем. просто мне не нравится то, как приминяются сессии тут.
главное не путать задачу встроенного механизма сессий для бложиков и "лэндингов" с суровой механикой аджайл бородачей и всем этим горизонтальным масштабированием. Это не для замены. Это такой удобный способ из коробки получить состояния на серевере поверх проткола http, который состояния не поддерживает. Вот и всё. И в 2017 и в 2020 говносайты какими были в 2000 были - такими и останутся. Для них придумано и работает отлично. Я люблю сессии в 2017 году, потому что 99% сайтов могут работать на одном сервере и не требуют масштабирования и соотв. идеально ложатся на session_start() большое счастье, что они ващпе применяются.
Тоже решил сделать, правда основной целью было поиграться с Slim 3.0, поскольку подходящего заказа пока не было. Так что может со временем я туда ещё каких-нибудь фитчей придумаю, чтоб разные возможности попользовать Slim. Так что всё на фреймворке. Ну раз сделал, почему бы не выложить? Поиграться: http://e.bug.kmk.4nmv.ru, код https://github.com/mike-kramer/example.
передо мной не стояло задачи делать сайты. а говносайты может потому и есть говносайты что под каждого пользователя нужно в памяти место выделить на это? или я что -то не так понимаю и сессии пользователя нужны на сервере?, почему не хранить их на машине клиента? как по мне это идиотизм особенно в реалиях того, что эти самые говоносайты обычно хостятся там, где ресурсы очень ограниченны.
Ты и так выделяешь его. БД, редис, прочая хрень тоже на сервере крутятся не на винте, так в оперативе, а не в параллельном измерении. Например потому, что в сессии удобно хранить, скажем, права доступа. Или статус аутентификации. Или "отпечатки пальцев", помогающие понять, не была ли сессия украдена или подделана. Нужно объяснять, почему это не должно храниться на клиенте? И уж тем более не должно при каждом чихе писаться/читаться в/из БД. 95% такой информации считаются всего один раз при логине пользователя, после чего не меняются на протяжении сессии. Сессии весят чуть больше, чем ничего. Первый том "Войны и Мира" чистым текстом весит 1,2мб. Если у тебя на сервере есть всего лишь гиг свободного места, один жалкий гиг, ты уже туда можешь напихать почти тысячу сессий, в каждой из которых будет храниться по тому "Войны и Мира". Это тысяча пользователей единомоментно на сайте. Это уже относительно высокая посещаемость. Это уже круто. А представляешь, сколько пользователей можно в гиг упихнуть, если хранить в сесси всего по нескольку байт данных, которые в куку умещаются, а не произведения Толстого? И поверь, когда у тебя на говнохостинге разом будет сидеть столько народу, сколько надо, чтобы сессии память вычерпали, это будет меньшая из твоих проблем.
хоть у меня и мало желания тут писать, поскольку слишком часто используется на этом ресурсе прием демагогии "Ad hominem" от людей с сомнительными высказываниями, вам все же отвечу. в том то и дело, что это все я понимаю, но как бы не банально это звучало -это в буквальном смысле для меня дело вкуса. Поясню, передо мной не стояло и не стоит задачи делать "сайты" (совсем и в принципе), ныне php я использовал 2-3 раза в качестве фронтенда веб клиенту, своеобразный лендинг (да даже вордпрес чисто роль лендинга выполняет), давая базовые возможности презентации и управления блогом, код практически не трогал, весь остальной функционал в вебе в последний случаях был на django и только по причине того, что python используется уже в проекте на других задачах и команда с ним отлично знакома. php мне нужен чтобы обойись без вещей вроде ворпреса и для начала нужно получить практику и понять "подводные камни". Еще раз я прекрасно знаю что такое механизм сессий и по прежнему считаю, что то о чем тут говорится - разные вещи. Хранение сеансов в бд \ редис и т.д. это только сверху аналогия сессий в пхп (как минимум доступ есть из разных мест, меня смущает то, что используется не мидлварь для хранения их а "стандартный" механизм тулзы (пхп) которую я не знаю. Я не понимаю, зачем мне ее использовать потому, как мне не понятно, как вешанье куки вызовом встроенной функции отличается от того, что я делаю явно или зачем мне нужны эти файлы сессий. На сколько я понимаю механизм их работы в пхп наибольший смысл они несут в момент сохранения состояния между закрытием \ повторным открытием браузера и это отличное решение например для корзины товаров, хотя тоже спорно. Зачем оно мне если проверяя валидность данных пользователя я даю ему положительный ответ и вешаю куку с токеном (не важно где его сохраняю, но на клиенте), чем я хуже сессии делающей тоже? Более того мне не нужен доступ к массиву $_SESSION и вохможность хранить там что -то еще, это избыточная фича, мне нужен только токен. ВСЕ, закрыл или открыл браузер не важно, токен есть. В базе хранится он с указанием прав доступа на случай потери состояния приложением в целом, никто не будет ходить его проверять, на это есть мидлварь, которая знает его время жизни... приложение крутится на сервере, пользователь удаляет куку и возвращается - проверка через мидлварь, время жизни для его данных логина еще действительно - в базу никто не идет... в базу обращение идет только по исечении времени жизни токена или после переагрузки сервера, когда состояние будет потерянно. И еще раз я делал подобный механизм (скорее другие детали подобных приложений) если не сотни, то более пары десятков раз, подобным образом это работает в массе не пхпшных веб фреймворков... Да я благодарен за подсказки, ревью кода и тыканье в мои ошибки. Да у меня куча вопросов и я много чего не понимаю, поскольку разбираюсь по задаче, у меня по прежнему нет времени пойти почитать книжку по пхп и все идет по ходу... но в данном случае по поводу сессий еще раз... я хорошо знаю что это за механизм, он меня не устраивает. Да возможно с памятью тут проблем и не будет, если это просто файлы, я не уверен, говорите, что нет - ок, исходников я не видел пока... Думаю этот вопрос можно закрыть, пока я нашел другой ресурс и таки предпочту избегать рунета и дальше, мне действительно малоприятно пока сюда возвращаться, потому как общаться там, где переходят на личности давая оценку качествам вне вопроса считаю дурным тоном... первую программу свою на бейсике я написал в 1989 году... да была отличная школа. Это может быть странно, но я не работал с серверными технологиями и базами в веб приложениях и сейчас пытаюсь это исправить. Но манера общения молокосов с мягко говоря сомнтительными аргументами и тем более жизненным и профессиональным опытом меня раздражает (и да в данном случая я не о вас, просто заканчиваю мысль и поясняю, что игнорирую в дальнейшем темы не по причине "слива", а по причине привычки к другому обществу и банальному желанию оставить гавно там, где оно есть и не трогать его...) удачи..