Чтобы понять как защитить, нужно понять как взламывают. Чтобы понять как взламывают нужно смотреть логи веб-сервера так как точка входа в уязвимость вероятнее всего там. Если вы каким-то образом узнали, что кто-то гулял по вашей панели администратора, значит вам должны быть известны какие-то данные, например пользователь который гулял, дата когда гуляли, урл по которому гуляли. Этих данных достаточно, чтобы отфильтровать логи по дате, по пользователю, по урлу и проанализировать какие запросы были сделаны в это время, по такому-то урлу, таким-то пользователем. Как правило сразу всё станет очевидно и ясно где дыра, а сидеть и генерировать предположения дело довольно бесполезное.
xmoonlight, там не рассказывают как делать правильно или неправильно, там лишь речь о том, как игры устроены внутри. Каким образом генерируется кадр и тому подобное. Чтобы человек имел представление о чем-то еще, кроме как нажимания кнопок в редакторе.
smilingcheater, html страницы это да, 1.2 мб против 400 кб у эталона, но там еще и TTFB 640-700 ms у автора против 40-70 ms у эталона. Посмотрел другие битрикс каталоги и все примерно с таким ttfb и отдаются. Соответственно проблема вероятнее всего с кодом битрикса. Никому неизвестно сколько всего там вычисляется прежде чем результат будет передан веб-серверу. Нужно распутывать километры спагетти-кода чтобы разобраться что там понаписали разработчики этого решения, но проще забить.
Евгений Ромашкан, Фаулер считает анемичную модель анти-паттерном, но бизнес-логику в сервисах без модели вообще - он считает нормальным решением и называет это transaction scripts. Такую же мысль в своих книгах доносят и другие известные инженеры. Посыл следующий или пишите процедурно или пишите объектно-ориентированно. Не делайте нечто среднее, то есть анемичную модель + процедуры в сервисах, так как не получите никаких преимуществ перед transaction scripts, но получите всю сложность domain model. Ну и тот же Фаулер ничего против rich model с использованием Active Record не имеет, указывая в своей книге PoEAA на то, что это некий компромисс между transaction scripts и domain model.
Только всякие хейтеры в интернете пишут, процедуры говно, active record анти-паттерн и нарушает принцип единой ответственности, что можно оспорить и вроде это даже делается прямо у Фаулера в PoEAA. Нужно просто иметь прямые руки и осознавать трейд-оффы каждого из решения которое предлагается к проектированию бизнес-логики.
Adamos, можно подумать, что государство настолько ужасное, что ты ходишь в разорванных трусах и живешь в картонной коробке, а вот было бы другое, то ты наверное точно купил бы самолет с яхтой, ну или хотя бы новую BMW. Люди, которые сумели создать свои компании, не ноют, не кричат как всё ужасно, не тащат всюду политику, а работают, обеспечивают работой других и создают ввп страны. Мнение таких людей может иметь значение. Мнение крикунов - нет, которых к тому же используют люди, некоторые из которых уже были ранее во власти и что-то как-то эдемов сад построить не сумели.
Rufix, данный ответ не совсем корректен, webpack - это не таскраннер, хотя его можно использовать как таковой, но это примерно как топором забивать гвозди. Смотрите мой ответ.
Антон Р., вы можете, команда angular лишь говорит, поскольку сам html - язык декларативный, то давайте продолжим и сделаем его динамическим в такой же парадигме. Что логично, но соглашаться с этим или нет выбор каждого.
Я не знаю какой самодисциплиной необходимо обладать, чтобы делать динамический UI без подобного помошника. Как правило это заканчивается тем, что манипуляция с dom, бизнес-логика и работа с сетью - все смешивается в одну кучу, без unit тестов, без tdd. Это может быть ок, для аутсорсинговой компании или фриланса с дешевыми сайтами на CMS. Но для продуктовой компании несколько странно.
Владимир Коротенко, пруфа на статистику нет, но даже если итак, то наверное все 90% спят и видят как бы подарить свои данные какому-нибудь сервису. Наверное очень сильно хотят получать уведомления о различных промо акциях на свой емайл.
Альтернатива всегда должна быть. Помоему это очевидно.
Владимир Коротенко, откуда вы знаете, что у пользователя есть аккаунты на тех сервисах, которые вы решили использовать в качестве oauth провайдера. Почему вы считаете, что пользователь должен хотеть шарить данные с этих сервисов с вами, особенно на запись. Почему вы предлагаете усложнить UX двухфакторной аутентификацией там, где это не требуется. Почему вообще нужно тратить кучу времени на это всё, когда требуется просто вход по паролю.
Пользуясь вашей аналогией нужно вообще тогда пароли в открытом виде хранить. Но вы почему-то хотите именно md5, который ни туда ни сюда. Зачем вам вообще какое-либо хеширование? Всё равно же всё уже украли исходя из вашей логики.
Владимир Коротенко, то есть для вас вычислительная сложность алгоритма не имеет значения? Отличная забота о пользователях. Знать бы им, что компрометация ваших md5 паролей может привести к угону не только аккаунта на вашем сервисе, но и на других обычным перебором по различным словарям и сравнением полученных результатов с результатами в базе данных из-за своей очень низкой вычислительной сложности.
Катя Смирнова, нормальное решение, но достаточно одного redis канала, на который подписан сам вебсокет-сервер. Комнаты для сокетов - это избыточно, так как правило сервис, который пушит сообщение знает, каким получателям его нужно отправить, например по id пользователя, который можно хранить напрямую в сокет-соединении. Каналы/комнаты и тому подобное в любом случае никак не помогут более эффективно рассылать сообщения в сокеты.
Я бы лучше подумал над тем, как клиенты будут потреблять данные от веб-сокет сервера. Сейчас популярно подписывать клиента на ряд событий "userBlocked", "userActivated" и так далее, в итоге клиент следит за событиями, вместо того, чтобы один раз подписаться и следить за самой сущностью user и при изменениях получать её новое состояние.
АртемЪ, цензура - нужна, но то, что происходит сегодня, это не цензура, а борьба с политически нежелательной информацией. Здесь и речи нет о подрыве моральных ценностей, устоев или чем-то подобном. Всё что блокируют - это 99% о политике, что честно уже утомило. Нарушает закон - изолируйте от общества или еще как-то воздействуйте на самого гражданина, но не на сервис, который использует данный гражданин для распространения своих идей, да еще и таким варварским способом, что страдает всё вокруг.
Лично мне это никаких особых проблем не доставляет - если сильно нужно, можно и через VPN зайти
Вам не доставляет. Кому-то доставляет. Проблема есть. Решения нет. Случайно блокировали и npm и другие сервисы и если вам "сильно нужно", то для кого-то это 99% времени в сети и не для развлечения, а для работы.
Сейчас требуется писать сообщение на почту с просьбой разблокировать, которую еще попробуй найди на сайте РКН, 30 дней на то, что это письмо вообще кто-то прочитает и половина года на то, чтобы наконец-то что-то исправили.
Можно по крайней мере сделать хотя бы плагин к браузеру, чтобы одной кнопкой отправлять запросы о неправомерном ограничении доступа к сайту. На стороне РКН может скрипт по базе проверить заблокирован ресурс или нет и принять необходимое решение за доли секунды, но там живой человек сидит выполняющий сизифов труд, который мы все оплачиваем.
Когда за VPN будет 99% пользователей, то и за них возьмутся. Вопрос уже обсуждался. Не понимаю как можно поддерживать позицию государства в этом вопросе, которое считает вас неспособным самостоятельно анализировать поступающую информацию.
phenya, так эти доменные события изначально какой-то кривой хак. Сколько проблем они создают, вызовы какого-нибудь DomainEventService.publish(event) внутри агрегатов или создание подобного функционала на самом агрегате. Никак не меняющие состояние объекта методы типа $catalog->remove(). Вынос мозга с попытками придумать, как атомарно сохранять эти события вместе с агрегатом, учитывая, что базы бывают NoSQL где нет транзакций вообще. Потом эти события как-то нужно удалять, когда все подписчики его обработали, что тоже проблема, поскольку неизвестно вообще сколько этих подписчиков. Как-то менеджить фейловые сценарии ну и так далее. Всю эту фигню на событиях, которая получается тоже называют Saga, но Сhoreography.
У Вон Вернона в книге вот такая диаграмма.
Чего здесь только нет. Паблишеры, подписчики, хранилища, очереди, двухфазовые коммиты. Всё это развалится на боевом проекте очень быстро.
Доменные события может быть еще имеют место в event-sourcing архитектуре, но в обычной многоуровневой архитектуре от них одни проблемы.
На чем основывается утверждение? Есть тест https://vc.ru/seo/69857-seo-test-indeksaciya-javas... и google и yandex по результатам тестов умеют индексировать javascript сайты. Google еще вроде в 2014 официально объявил, что они умеют индексировать javascript сайты. Яндекс вроде до сих пор этого не сделал, но по факту тестов видно, что тоже умеет.
Adamos, ну ок, но я такую реализацию этого паттерна в своем коде видеть не желаю. Заглядывать в него будут постоянно, чтобы добавить новый if. Объем кода будет бесконтрольно расти, удалить ненужный хлам тяжело, так как неизвестно используется он еще где-то или нет. Паттерн - ок, имеет место быть. Примеры его реализации - отстой.
Adamos, да, если у клиента есть пачка различных адресов в перемешку к локальным и удаленным файлам, тогда нечто похожее на "простую фабрику" действительно требуется. Но это не значит, что нужно внутри неё городить забор из операторов ветвления, так как эти источники как правило стандартизированы и по протоколу или по расширению файла можно напрямую сконвертироваться в нужное имя класса. Чтобы поддерживать еще одно расширение достаточно написать новый класс без изменения самого класса фабрики тем самым не нарушая open-closed principle. В случае с простой фабрикой нужно будет зайти и добавить еще один if или case. Такой код не SOLID, он пахнет и его сразу видно, потому что он именно так и выглядит, как свалка из всяких ветвлений. Сложно такое назвать "паттерном".
