ок, ок… наверно я что-то делаю не так, но мне за последние 15 лет ни разу не пришлось использовать встраиваемые скрипты с небезопасным содержимым…
И меня смутило долгое вступление про общие проблемы html, требующие аккуратного экранирования пользовательских данных.
Но если рассматривать safescript исключительно как разрешение конфликта парсеров html и script — то идея может и годная.
Но суть-то не меняется — пока что-то встраивается в код страницы минуя соответствующее экранирование, проблема будет сохраняться.
И кто защитит safescript от подобных проблем?
А я вот всё в толк не возьму, что за проблему предлагается решать столь неоднозначным способом?
Возможность "вредоносным" пользователем встроить произвольное содержание в ваш документ — это скорее фундаментальный баг разработчика. Оное содержимое может оказаться в любом месте документа, ведь никто не мешает в качестве имени при регистрации указать:
Вася"><script>alert("Aloha!");</script>
и продолжить сей фрагмент остатком оригинального тэга. Т.е. это проблема всей разметки, а не исключительно тэга script.
Точно так же и в safescript можно включить любую ересь.
Правильно говорят — на странице должен быть только константный или тщательно проверенный и экранированный контент. Остальное данные и работа с DOM. Других способов защиты нет.
<sarcasm>
ну и далее нужна картинка про 15-й стандарт :)
</sarcasm>
Да, в автомаппере гибкости много.
Да и у вас кода не мало. Может с автомапером кода в конфигурации станет чуть больше, но обвязки станет меньше, как мне кажется… да и дебажить и тестировать такой подход проще.
Или есть принципиальная потребность хранить правила в виде текста вне кода программы?
(тут, кстати, тоже есть варианты, как прикрутить конфиг из текста к автомапперу)
Может я что не так понял в постановке задачи, но почему не захотели использовать AutoMapper (или аналог) в связке с (де)сериализаторами, которые вместе можно положить в DI-контейнер и получить и мощь, и простоту, и конфигурируемость?
У меня была похожа задача — мы реализовывали работу с внешними клиентами по разным протоколам и не хотели писать конвертеры входных/выходных данных для каждого протокола/клиента (от клиента зависели некоторые правила преобразования и контроля данных). В итоге у нас получилась цепочка: входной формат — десериализация — конвертация во внутреннее представление — обработка — конвертация во внешнее представление — сериализация — выходной формат.
Через контейнер настраивались и конвертаторы и сериализаторы. На каждом этапе (включая обработку) через тот же контейнер были доступны компоненты для доступа к данным…
Ох, зря Вы так… Ведь и правда закидают.
Ваша реализация крайне небезопасна. С точки зрения механизма, у вас не токен, а сессионная кука.
Но хуже всего сама аутентификация. Серьёзно, поиск по частичному совпадению логина и пароль с чистом виде?
Настольный теннис зря забыли.
Очень поднимает тонус и годен как разминка прямо на работе.
Круглогидичен. Для начала требует минимум вложений. Занимает почти все группы мышц (не
качает, ясно дело). При правильных занятиях развивает гибкость, координацию, реакцию. Снимает застойные явления (от сидячей работы) по всему телу, особенно позвоночник и руки. А ещё это и тренировка для глаз. Низкая травмоопасность.
Существенный минус — нужен зал.
Дополнительный бонус — легко вписаться в любительские соревнования, чем добавить себе разнообразия и стимула.
И да, если заниматься серьёзно — это неплохой удар по лишнему весу.
И заниматься можно даже с избытком веса.
Тут во флэшку запихали кулхацкера, который быстро-быстро что-то печатает на клавиатуре компа :)
Т.е. тупо автоматизация того, что можно сделать и так, имея доступ к компу.
«Взлом» получится только если убедить пользователя самого воткнуть флэшку в свой комп.
Я не скажу за все СУБД, мой опыт в этой сфере ограничивается MS SQL, но решение как бы есть :)
На двух довольно ёмких и длительных проектах был успешно применён подход, реализующий оба затрагиваемых принципа. Корень подхода — дисциплина внесения изменений.
Первое железобетонное правило, за нарушение которого «били по рукам» — все изменения начинаются с написания скрипта. Никаких дизайнеров или ковыряния в базе.
Второе — скрипты должны быть не ломающими. Да, кода получается сильно больше. Приходится DDL обкладывать проверками. Но если один раз привыкнуть писать эти скрипты по определённому шаблону — оно оказывается не так уж и сложно. Одна проблема — пока не удалось автоматизировать эту работу, хотя и есть понимание, от чего можно отталкиваться и как делать. Не было времени создать инструмент. Зато эти скрипты отлично ложатся в tfs/git/etc и по истории проекта легко отслеживается суть изменений. При этом накат скриптов на базу легко автоматизируется.
Третье, уже вывод из многих раздумий… Я понимаю, почему разработчики СУБД не предлагают ничего похожего на CONVERGE — уж слишком легко сломать и не вернуть (одно спасение — бэкапы). Суть проблемы в том, что при редактировании кода мы не можем потерять клиентские данные, за их целостность отвечает тестирование продукта, а код — это только текст. Схема данных — это данные, на основании которых определяется стратегия хранения клиентских данных, и внесение изменений влечёт серьёзные последствия. И никакой инструмент не позволит себе решать, какое изменения в данных корректно, а какое нет. И по сути останутся только изменения, не модифицирующие данные, т.е. костыль.
Ах, да, суть подхода, кратко — каждое изменение атомарно, как транзакция. Обрамляется проверкой предусловий, завершается 'go'. Изменения одной задачи объединяются в один скрипт, проверяющий некую мета-информацию о базе с условием допустимости выполнения (например версию БД). Как итог — накатывать можно всю порцию скриптов. Устаревшие игнорируются, слишком новые выкидывают фатальные ошибки.
Поделюсь личным опытом. Пользуюсь Делимобилем, Белкой и Энитаймом, в сумме года два, примерно.
У делимобиля уже давно есть телеграм-поддержка, куда можно, например, написать про повреждения, приложить фотки и спокойно ехать. Раньше надо было звонить и ждать ответа оператора (по многу минут), а фотки можно было только на почту послать.
Карта у них не то, чтобы убогая, но гугловая. Путь к машине показывает, и даже пишет, сколько идти. И ещё прикольная фишка — если рядом нет машин, но вы никуда не торопитесь, можно включить «радар» и приложение вам сообщит, если в заданном радиусе появится свободная машина. Имхо, удобно где-нибудь в центе в торговом центре или кафе…
С омывайкой проблема весьма актуальна зимой, но можно купить и прислать в телеграм фото чека, обещают компенсировать (до 300р за 5 литров). Проблема только в том, что чаще всего в радиусе 5 минут от машины негде купить. Но нередко в багажнике есть запасная.
Есть ещё телеграм-бот, помогающий разобраться со стандартными проблемами.
Заправка у них только на Лукойл или Ека, по отдельным карточкам. Но для активации карты надо звонить стоя на заправке (но за последние полгода ни разу не ждал ответа более 15 секунд).
Приложение не глючит (почти). Из заметных проблем — это серьёзное обновление серверного ПО. Было время, когда авторизация слетала (давно уже). Было однажды (недели две-три чинили) когда можно было в приложении делать всё, кроме начала аренды. Оную только по звонку. Ну да, пламенный пример бэкендщикам и тестировщикам. И ещё в копилку — жутко раздражает карта, которая всё время норовит перейти в масштаб «весь город», что сразу после бронирования, что пока идёшь к машине…
При начале поездки есть возможность отказаться от дополнительной страховки за 1р/м, по умолчанию опция включена.
У белки приложение более функциональное. Найти и осуществить заправку можно через приложение. Но есть и проблемка — кнопка начала аренды примерно там, где приходится держать телефон, пока ищешь его на карте. Можно случайно нажать и потом карту уже не открыть, а машина стоит с открытыми дверями.
Кроме Киа Рио бывают Форд Фиеста, это кроме мерсов :). У Киа руль с подогревом — зимой полезно. Но почему-то нет центрального замка (ну или я не нашёл), приходится перед поездкой все двери закрывать.
Емнип, можно в настройка включить доп. страховку на время движения.
Еще они в реальном времени списывают каждые 300р оплаты (не помню, что там в правилах на тот случай, если оплата не получится).
У энитайма всё как-то иначе. Да, карты яндекс, но жутко тормозные. Что в режиме отрисовки, что пока идёшь к машине (твои координаты на карте обновляются раз-два в минуту и часто с точностью +-100 метров, что сильно мешает, пока ищешь машину во дворах).
Если в режиме аренды приложение выгрузилось по любой причине, запускается очень долго (на днях минут 5 стоял возле машины только чтобы завершить аренду).
Раньше у них тоже была только предоплата, теперь обязали привязать карту с безакцептным списанием. Но можно счёт пополнить и не только картой.
Но да, танцы с фотографированием каждый раз раздражают.
Зато (надеюсь это и сейчас так, не проверял) режим аренда/ожидание определяется автоматически (т.е. ожидание включается если двигатель заглушён и двери закрыты).
И общий вопрос-замечание: ну почему ни в одном приложении нет навигатора? хоть самого простого, какой есть в обычных картах?
А вот тут я бы поспорил…
Я не вспомню «чистое» определение, но, насколько я помню, и то и то может иметь динамический размер и разница у них в организации доступа и добавления элементов.
В том же курсе, вроде как, рассматриваются очереди и стэки…
А ещё можно повспоминать про сложность обращения к элементу и сложность вставки/удаления…
А список бывает ещё и связный и кольцевой…
Эх, с понимающим кандидатом есть что обсудить ;)
Как так-то?
Если вообще… То мне придётся вспомнить то, что изучал более 20 лет назад в чистом виде, без привязки к языку и контексту никогда не использовал. И не уверен, что вспомню что-то похоже на ту правильную формулировку, которую ожидает вопрошающий. Меня такой вопрос на собеседовании напряжёт, и даст понять, что меня тут заранее не уважают.
Но всё же, мой ответ был бы в духе «список — структура с последовательным доступом, а массив с произвольным», хотя я точно знаю, что в C# внутри List лежит Array…
Ну вот опять, набежали комментаторы :), которые путают сложность решаемых задач с качеством подхода к работе.
Если не делать разделение на кодеров и программистов, то да, рулит именно самосознание и самодисциплина… Но профит-то не в том.
И дело даже не джниорах и сеньорах, ибо деление чаще всего только по опыту и желаемой зарплате.
Просто у кодера и программиста разные задачи. Если нужно превратить в код тонну более или менее качественного ТЗ — это работа кодера, и программист загнётся со скуки.
А если в ТЗ преимущественно «сделай мне красиво» :) — то для программиста, ибо кодер просто не будет знать, что делать.
Как уже сказали выше, без подписи исходники не нужны для того, чтобы скомпилировать модифицированную версию.
А тут ни подписи, ни обфускации… никакой защиты.
Что-то ни eset, ни drweb не упомянули, имела ли бэкдорная либа цифровую подпись?
Если да, то внедрить коня без доступа к билд-серверу или полным исходникам не получилось бы. А если подписи нет… то бардак и несоблюдение базовых правил публикации, привели к возможности вот так влёгкую заразить всё и вся…
Как говорится, вот только не надо обобщать.
В моём случае на качество сна кофе не влияет от слова никак. Совершенно спокойно могу выпить чашечку и тут же лечь спать (более того, если я сильно ментально утомлён, то спать захочется немедленно). И бодрость поутру будет завить только от того, сколько я спал и чем занимался накануне :)
Всё же, тут многое зависит как от индивидуальной биохимии организма, так и от личного энергобаланса. И мои наблюдения подсказывают, что изменить и то и другое может и можно, но в большинстве случаев крайне сложно… и очень трудно найти новый баланс. Но это не считая тех, кто неэффективно использует свои ресурсы.
Это вот то самое! Кого именно называть программистом? Дайте однозначное определение, и можно будет сделать перечисление тех самых базовых навыков. А без этого, ответ один — программист должен, как минимум, уметь программировать ;)
Я может по сути уже давно и не программист, но до сих пор пишу код, и этот код работает хорошо и приносит заказчику прибыль, а коллегам не приносит лишней головной боли… Но даже если брать времена весьма далёкие, я также, как и сейчас, почти не сталкивался с потребностью явно писать сложные алгоритмы. И мой продукт не был хуже от того, что я не знал эти алгоритмы.
Говоря про ваши примеры, у меня первый вопрос в голове — а зачем это нужно? какие данные на входе, что нужно на выходе? в каком case это будет использоваться? Ведь даже тот же неупорядоченный массив… Мне чаще встречаются задачи вида «выбрать из массивасписка элементы, для которых выполняется бизнес-условие, и преобразовать элементы в другой вид». В большинстве случаев никакие пред-сортировки и прочие шаманства не дадут ничего, кроме лишнего кода. А оптимизации чаще всего лежат на несколько уровней выше конкретного участка кода…
И уж совсем отдельный вопрос, что же такое «базовые алгоритмы»? :)
Знание каких базовых алгоритмов помогло бы в 2000-м превратить обычный asp-сайт в веб-ферму?
И меня смутило долгое вступление про общие проблемы html, требующие аккуратного экранирования пользовательских данных.
Но если рассматривать safescript исключительно как разрешение конфликта парсеров html и script — то идея может и годная.
А заголовок всё же слишком громкий :)
И кто защитит safescript от подобных проблем?
А я вот всё в толк не возьму, что за проблему предлагается решать столь неоднозначным способом?
Возможность "вредоносным" пользователем встроить произвольное содержание в ваш документ — это скорее фундаментальный баг разработчика. Оное содержимое может оказаться в любом месте документа, ведь никто не мешает в качестве имени при регистрации указать:
и продолжить сей фрагмент остатком оригинального тэга. Т.е. это проблема всей разметки, а не исключительно тэга script.
Точно так же и в safescript можно включить любую ересь.
Правильно говорят — на странице должен быть только константный или тщательно проверенный и экранированный контент. Остальное данные и работа с DOM. Других способов защиты нет.
<sarcasm>
ну и далее нужна картинка про 15-й стандарт :)
</sarcasm>
Да и у вас кода не мало. Может с автомапером кода в конфигурации станет чуть больше, но обвязки станет меньше, как мне кажется… да и дебажить и тестировать такой подход проще.
Или есть принципиальная потребность хранить правила в виде текста вне кода программы?
(тут, кстати, тоже есть варианты, как прикрутить конфиг из текста к автомапперу)
У меня была похожа задача — мы реализовывали работу с внешними клиентами по разным протоколам и не хотели писать конвертеры входных/выходных данных для каждого протокола/клиента (от клиента зависели некоторые правила преобразования и контроля данных). В итоге у нас получилась цепочка: входной формат — десериализация — конвертация во внутреннее представление — обработка — конвертация во внешнее представление — сериализация — выходной формат.
Через контейнер настраивались и конвертаторы и сериализаторы. На каждом этапе (включая обработку) через тот же контейнер были доступны компоненты для доступа к данным…
Ваша реализация крайне небезопасна. С точки зрения механизма, у вас не токен, а сессионная кука.
Но хуже всего сама аутентификация. Серьёзно, поиск по частичному совпадению логина и пароль с чистом виде?
Очень поднимает тонус и годен как разминка прямо на работе.
Круглогидичен. Для начала требует минимум вложений. Занимает почти все группы мышц (не
качает, ясно дело). При правильных занятиях развивает гибкость, координацию, реакцию. Снимает застойные явления (от сидячей работы) по всему телу, особенно позвоночник и руки. А ещё это и тренировка для глаз. Низкая травмоопасность.
Существенный минус — нужен зал.
Дополнительный бонус — легко вписаться в любительские соревнования, чем добавить себе разнообразия и стимула.
И да, если заниматься серьёзно — это неплохой удар по лишнему весу.
И заниматься можно даже с избытком веса.
Т.е.
тупоавтоматизация того, что можно сделать и так, имея доступ к компу.«Взлом» получится только если убедить пользователя самого воткнуть флэшку в свой комп.
На двух довольно ёмких и длительных проектах был успешно применён подход, реализующий оба затрагиваемых принципа. Корень подхода — дисциплина внесения изменений.
Первое железобетонное правило, за нарушение которого «били по рукам» — все изменения начинаются с написания скрипта. Никаких дизайнеров или ковыряния в базе.
Второе — скрипты должны быть не ломающими. Да, кода получается сильно больше. Приходится DDL обкладывать проверками. Но если один раз привыкнуть писать эти скрипты по определённому шаблону — оно оказывается не так уж и сложно. Одна проблема — пока не удалось автоматизировать эту работу, хотя и есть понимание, от чего можно отталкиваться и как делать. Не было времени создать инструмент. Зато эти скрипты отлично ложатся в tfs/git/etc и по истории проекта легко отслеживается суть изменений. При этом накат скриптов на базу легко автоматизируется.
Третье, уже вывод из многих раздумий… Я понимаю, почему разработчики СУБД не предлагают ничего похожего на CONVERGE — уж слишком легко сломать и не вернуть (одно спасение — бэкапы). Суть проблемы в том, что при редактировании кода мы не можем потерять клиентские данные, за их целостность отвечает тестирование продукта, а код — это только текст. Схема данных — это данные, на основании которых определяется стратегия хранения клиентских данных, и внесение изменений влечёт серьёзные последствия. И никакой инструмент не позволит себе решать, какое изменения в данных корректно, а какое нет. И по сути останутся только изменения, не модифицирующие данные, т.е. костыль.
Ах, да, суть подхода, кратко — каждое изменение атомарно, как транзакция. Обрамляется проверкой предусловий, завершается 'go'. Изменения одной задачи объединяются в один скрипт, проверяющий некую мета-информацию о базе с условием допустимости выполнения (например версию БД). Как итог — накатывать можно всю порцию скриптов. Устаревшие игнорируются, слишком новые выкидывают фатальные ошибки.
У делимобиля уже давно есть телеграм-поддержка, куда можно, например, написать про повреждения, приложить фотки и спокойно ехать. Раньше надо было звонить и ждать ответа оператора (по многу минут), а фотки можно было только на почту послать.
Карта у них не то, чтобы убогая, но гугловая. Путь к машине показывает, и даже пишет, сколько идти. И ещё прикольная фишка — если рядом нет машин, но вы никуда не торопитесь, можно включить «радар» и приложение вам сообщит, если в заданном радиусе появится свободная машина. Имхо, удобно где-нибудь в центе в торговом центре или кафе…
С омывайкой проблема весьма актуальна зимой, но можно купить и прислать в телеграм фото чека, обещают компенсировать (до 300р за 5 литров). Проблема только в том, что чаще всего в радиусе 5 минут от машины негде купить. Но нередко в багажнике есть запасная.
Есть ещё телеграм-бот, помогающий разобраться со стандартными проблемами.
Заправка у них только на Лукойл или Ека, по отдельным карточкам. Но для активации карты надо звонить стоя на заправке (но за последние полгода ни разу не ждал ответа более 15 секунд).
Приложение не глючит (почти). Из заметных проблем — это серьёзное обновление серверного ПО. Было время, когда авторизация слетала (давно уже). Было однажды (недели две-три чинили) когда можно было в приложении делать всё, кроме начала аренды. Оную только по звонку. Ну да, пламенный пример бэкендщикам и тестировщикам. И ещё в копилку — жутко раздражает карта, которая всё время норовит перейти в масштаб «весь город», что сразу после бронирования, что пока идёшь к машине…
При начале поездки есть возможность отказаться от дополнительной страховки за 1р/м, по умолчанию опция включена.
У белки приложение более функциональное. Найти и осуществить заправку можно через приложение. Но есть и проблемка — кнопка начала аренды примерно там, где приходится держать телефон, пока ищешь его на карте. Можно случайно нажать и потом карту уже не открыть, а машина стоит с открытыми дверями.
Кроме Киа Рио бывают Форд Фиеста, это кроме мерсов :). У Киа руль с подогревом — зимой полезно. Но почему-то нет центрального замка (ну или я не нашёл), приходится перед поездкой все двери закрывать.
Емнип, можно в настройка включить доп. страховку на время движения.
Еще они в реальном времени списывают каждые 300р оплаты (не помню, что там в правилах на тот случай, если оплата не получится).
У энитайма всё как-то иначе. Да, карты яндекс, но жутко тормозные. Что в режиме отрисовки, что пока идёшь к машине (твои координаты на карте обновляются раз-два в минуту и часто с точностью +-100 метров, что сильно мешает, пока ищешь машину во дворах).
Если в режиме аренды приложение выгрузилось по любой причине, запускается очень долго (на днях минут 5 стоял возле машины только чтобы завершить аренду).
Раньше у них тоже была только предоплата, теперь обязали привязать карту с безакцептным списанием. Но можно счёт пополнить и не только картой.
Но да, танцы с фотографированием каждый раз раздражают.
Зато (надеюсь это и сейчас так, не проверял) режим аренда/ожидание определяется автоматически (т.е. ожидание включается если двигатель заглушён и двери закрыты).
И общий вопрос-замечание: ну почему ни в одном приложении нет навигатора? хоть самого простого, какой есть в обычных картах?
Я не вспомню «чистое» определение, но, насколько я помню, и то и то может иметь динамический размер и разница у них в организации доступа и добавления элементов.
В том же курсе, вроде как, рассматриваются очереди и стэки…
А ещё можно повспоминать про сложность обращения к элементу и сложность вставки/удаления…
А список бывает ещё и связный и кольцевой…
Эх, с понимающим кандидатом есть что обсудить ;)
Но реально, часто задают такие вопросы ожидая ровно одного «правильного» ответа :(
Если вообще… То мне придётся вспомнить то, что изучал более 20 лет назад в чистом виде, без привязки к языку и контексту никогда не использовал. И не уверен, что вспомню что-то похоже на ту правильную формулировку, которую ожидает вопрошающий. Меня такой вопрос на собеседовании напряжёт, и даст понять, что меня тут заранее не уважают.
Но всё же, мой ответ был бы в духе «список — структура с последовательным доступом, а массив с произвольным», хотя я точно знаю, что в C# внутри List лежит Array…
Если не делать разделение на кодеров и программистов, то да, рулит именно самосознание и самодисциплина… Но профит-то не в том.
И дело даже не джниорах и сеньорах, ибо деление чаще всего только по опыту и желаемой зарплате.
Просто у кодера и программиста разные задачи. Если нужно превратить в код тонну более или менее качественного ТЗ — это работа кодера, и программист загнётся со скуки.
А если в ТЗ преимущественно «сделай мне красиво» :) — то для программиста, ибо кодер просто не будет знать, что делать.
А тут ни подписи, ни обфускации… никакой защиты.
Если да, то внедрить коня без доступа к билд-серверу или полным исходникам не получилось бы. А если подписи нет… то бардак и несоблюдение базовых правил публикации, привели к возможности вот так влёгкую заразить всё и вся…
В моём случае на качество сна кофе не влияет от слова никак. Совершенно спокойно могу выпить чашечку и тут же лечь спать (более того, если я сильно ментально утомлён, то спать захочется немедленно). И бодрость поутру будет завить только от того, сколько я спал и чем занимался накануне :)
Всё же, тут многое зависит как от индивидуальной биохимии организма, так и от личного энергобаланса. И мои наблюдения подсказывают, что изменить и то и другое может и можно, но в большинстве случаев крайне сложно… и очень трудно найти новый баланс. Но это не считая тех, кто неэффективно использует свои ресурсы.
Говоря про ваши примеры, у меня первый вопрос в голове — а зачем это нужно? какие данные на входе, что нужно на выходе? в каком case это будет использоваться? Ведь даже тот же неупорядоченный массив… Мне чаще встречаются задачи вида «выбрать из
массивасписка элементы, для которых выполняется бизнес-условие, и преобразовать элементы в другой вид». В большинстве случаев никакие пред-сортировки и прочие шаманства не дадут ничего, кроме лишнего кода. А оптимизации чаще всего лежат на несколько уровней выше конкретного участка кода…И уж совсем отдельный вопрос, что же такое «базовые алгоритмы»? :)
Знание каких базовых алгоритмов помогло бы в 2000-м превратить обычный asp-сайт в веб-ферму?