:-) Отключить второй фактор = "пилить фичи"? С учетом того что аутентификация по второму фактору появилась "как фича"? И кто и на основе каких данных решил что "эта фича" нужна "ничтожно малому количеству людей"? И если это "ничтожно малое количество людей" (в отличии от массы "не специалистов") отлично и четко понимают что реально необходимо именно им (не слушая маркетинговый бред поставщиков сервисов)? Не будьте как Apple которые заявляли что "copy/paste" нужен только "ничтожно малому количеству людей"... :-)
"Пользователь некомпетентен в большинстве слуваев." - это означает что все пользователи "некомпетентны" в конкретном случае? Или все же это означает "мы лучше вас знаем что вам нужно"? К примеру я пытался в нескольких банках отказаться от смс подтверждения операций, заявляя что готов подписать необходимый документ/заявление для банка что всю финансовую ответственность за это "беру на себя". И? Казалось бы, банк в этом случае ничем не рискует (имея от клиента такое заявление). Но нет... :-) "Мы лучше вас знаем что вам нужно..."
"Пользователь может желать иметь на всех своих аккаунтах пароль 1234 и никаких заморочек со вторым фактором." - и в чем проблема? Пусть имеет - это его законное желание, задача сервиса не "смотреть на лучшие стандарты и практики" а просто предупредить/научить пользователя "какие последствия могут быть" и что сервис за действия пользователя ответственности не несет (а почему собственно должен?), он должен предлагать различные варианты аутентификации, а не запрещать какие либо, а уж пользователь сам выберет удобный и безопасный (по его мнению) для него. Может MS или Google или Apple отказались от аутентификации по паролю без второго фактора? Или это для вас не "лучшие практики и стандарты "? :-)
"это необходимо для повышения безопасности аккаунтов пользователей и усиления защиты персональных данных клиентов госсервиса" - а сам пользователь госуслуг может решить нужно ему такое "усиление защиты и повышение безопасности" или нет? :-) Перенимают подход Apple к своим пользователям - "мы лучше знаем что вам нужно"? :-)
Статья понравилась. Но... Корень основных проблем скорее во фразах типа "разработчик не знает что там выдумает бизнес"... Ну естественно, если у вас "во главе угла" аджайл с девизом "быстро счас наклепаем то что кажется поняли, а потом разберемся" - никакая БД вам не поможет сделать то что сами вы не знаете... :-) И нужно четко понимать что "чудес не будет". Быстро, надежно, много и дешево одновременно не может быть "по определению", как бы вам этого не хотелось. Нужно искать балансы и определять приоритеты. И не нужно "пихать" в хранилище данных сырые xml и потом удивляться полученному результату (по производительности и/или ресурсам). Если вы используете в своих sql запросах связки из десятков таблиц (особенно с изменяемыми периодически в них объемами данных и множестве индексов) не удивляйтесь что стоимостные оптимизаторы БД периодически "сходят с ума"... Лучше подумайте как лично вы (как разработчик) можете "облегчить им жизнь" чтобы "переваривать" терабайты данных. Объекты это конечно хорошо (для разработчика), но "размазывать" их по множеству таблиц в БД - плохо, как и плохо делать выборку "объекта из базы" для получения в итоге одного хранимого в одной таблице поля.
Предлагаю вместо "напрасных приседаний" делать что-то полезное для приложения... Или же у вас много "лишних" ресурсов чтобы тратить их на бесполезную "защиту"? Поскольку те кто не может "в два клика" сам, могут почти всегда набрать нужную строку поиска в интернете... Или пример корпораций гигантов (с миллионными установками и пользователями) отказавшихся от проверок собственных приложений на предмет наличия root доступа клиента вам "не пример"? :-)
Т.е. прикладники не в курсе что такое отладчик или думают что их "защиту" сложно обойти парой ассемблерных инструкций? :-) Если прикладную "защиту" еще не сломали - в 90% случаев это значит что ваше "супер приложение" никому и не интересно... Хотя конечно прикладникам никто не мешает думать обратное... :-)
:-) Во многом это зависит от требований и условий... Насколько мне известно данные с датчиков баллистических ракет пишутся напрямую на носитель (без OS и fs). А вот для БД "общего назначения" к примеру та же Oracle от таких "финтов" как запись данных на "сырые устройства" (которой пользовалась множество версий) отказывается... По реальным тестам это давало +5% производительности и +25% "гемороя" администраторам серверов БД....
Современные "разработчики" много чего не знают и не умеют... Именно это их заставляет использовать монстрообразные фреймворки которые "еле ползают" на современных многоядерных CPU... Это же проще чем изучать основы и принципы функционирования компьютеров и OS.... :-) Именно такие "разработчики" пихают в базу "сырые" XML объекты...
"Опыт интернатур" - мало кого интересует (исключая тех кто за это получает себе доход)... Работодателей интересуют готовые специалисты требуемой квалификации... :-) Продавать "золотоискателям" "лопаты" рассказывая "сказки о возможностях скорого заработка"- всегда было выгодно.... :-)
А по вашему "middle+" уже такими рождаются? :-) Скорее "Полностью прошедший учебник + несколько месяцев интернатуры на реальном проекте будет" = "умею работать по шаблону и инструкции, а чему там нас учили уже не помню..." Примерно как учебники и курсы из серии - "Как заработать миллион за 3 месяца." :-)
:-) Как то так примерно... #chown root.root /bin/bash #chmod 700 /bin/bash ....... Для .app дать права +rx только пользователю с "нужным" id... У остальных отобрать.
:-) Да уж... Я еще понимаю когда разработчики OS под устройство "защищают" от получения root доступа... Но куда "впрягаются" и "надувают щеки" прикладники то? А главное это абсолютно безуспешно... Но видимо знание базовых принципов прав и разделения доступа в unix - им просто никто нормально не объяснил... :-)
Читая подобные статьи я всегда удивляюсь... Неужели поколение современных прикладных разработчиков не знает такой простой и давно известной истины, что пользователь с root правами (а jailbreak на IOS как и root на Android именно эти права и позволяют получить) может "скрыть" от любого другого пользователя или программы работающих не от root (а все пользовательские приложения на IOS и Android таких прав не имеют) наличие у себя таких прав или любого приложения/файла на устройстве. Для этого достаточно просто иметь или соответствующие знания OS (в частности unix) или соответствующий сторонний софт (которого так же достаточно, если собственных знаний у вас нет). Ну ладно законодатели (они "слышали звон, но не знают где он"), но IT то специалисты... Куда же катится уровень знаний современных разработчиков.... :-)
:-) Преимущество будет... Но только тогда, когда QA специалист не просто пройдет один (два или пять) курсов и узнает что такое БД и Linux (по курсам/учебникам типа вашим), а будет разбираться чем работа запросов в Oracle отличается от "аналогичных" в PostgeSQL (или MS SQL), и почему работа одного и того же (к примеру Java) приложения (на одном и том же сервере) в Windows вызывает другую нагрузку на ресурсы сервера чем в Linux, и по какой причине использование 2 серверов с 16 ядрами CPU может быть менее (или более) эффективно чем использование одного сервера с такими же 32 ядрами CPU.... Вот только попытки "впихнуть не впихуемое" в один курс (или учебник) "пробежав по верхам", а после этого заявлять "мы сделали крутую штуку и после ее вы станете крутым профессионалом!", не очень хорошо характеризует уровень знаний его составителей, скорее характеризует их амбиции... :-)
:-) Отключить второй фактор = "пилить фичи"? С учетом того что аутентификация по второму фактору появилась "как фича"? И кто и на основе каких данных решил что "эта фича" нужна "ничтожно малому количеству людей"? И если это "ничтожно малое количество людей" (в отличии от массы "не специалистов") отлично и четко понимают что реально необходимо именно им (не слушая маркетинговый бред поставщиков сервисов)? Не будьте как Apple которые заявляли что "copy/paste" нужен только "ничтожно малому количеству людей"... :-)
"Пользователь некомпетентен в большинстве слуваев." - это означает что все пользователи "некомпетентны" в конкретном случае? Или все же это означает "мы лучше вас знаем что вам нужно"? К примеру я пытался в нескольких банках отказаться от смс подтверждения операций, заявляя что готов подписать необходимый документ/заявление для банка что всю финансовую ответственность за это "беру на себя". И? Казалось бы, банк в этом случае ничем не рискует (имея от клиента такое заявление). Но нет... :-) "Мы лучше вас знаем что вам нужно..."
"Пользователь может желать иметь на всех своих аккаунтах пароль 1234 и никаких заморочек со вторым фактором." - и в чем проблема? Пусть имеет - это его законное желание, задача сервиса не "смотреть на лучшие стандарты и практики" а просто предупредить/научить пользователя "какие последствия могут быть" и что сервис за действия пользователя ответственности не несет (а почему собственно должен?), он должен предлагать различные варианты аутентификации, а не запрещать какие либо, а уж пользователь сам выберет удобный и безопасный (по его мнению) для него.
Может MS или Google или Apple отказались от аутентификации по паролю без второго фактора? Или это для вас не "лучшие практики и стандарты "? :-)
Проблема одна - на желание пользователя им .... :-)
Рекетиры тоже "защиту и безопасность" обеспечивают без вашего особого желания...
"это необходимо для повышения безопасности аккаунтов пользователей и усиления защиты персональных данных клиентов госсервиса" - а сам пользователь госуслуг может решить нужно ему такое "усиление защиты и повышение безопасности" или нет? :-)
Перенимают подход Apple к своим пользователям - "мы лучше знаем что вам нужно"? :-)
Статья понравилась. Но...
Корень основных проблем скорее во фразах типа "разработчик не знает что там выдумает бизнес"... Ну естественно, если у вас "во главе угла" аджайл с девизом "быстро счас наклепаем то что кажется поняли, а потом разберемся" - никакая БД вам не поможет сделать то что сами вы не знаете... :-)
И нужно четко понимать что "чудес не будет". Быстро, надежно, много и дешево одновременно не может быть "по определению", как бы вам этого не хотелось. Нужно искать балансы и определять приоритеты. И не нужно "пихать" в хранилище данных сырые xml и потом удивляться полученному результату (по производительности и/или ресурсам).
Если вы используете в своих sql запросах связки из десятков таблиц (особенно с изменяемыми периодически в них объемами данных и множестве индексов) не удивляйтесь что стоимостные оптимизаторы БД периодически "сходят с ума"... Лучше подумайте как лично вы (как разработчик) можете "облегчить им жизнь" чтобы "переваривать" терабайты данных.
Объекты это конечно хорошо (для разработчика), но "размазывать" их по множеству таблиц в БД - плохо, как и плохо делать выборку "объекта из базы" для получения в итоге одного хранимого в одной таблице поля.
? ФСБ ? :-) Что-то мобильных приложений с сертификатами ФСТЕК и ФСБ на OS общего назначения я не знаю... :-)
Предлагаю вместо "напрасных приседаний" делать что-то полезное для приложения... Или же у вас много "лишних" ресурсов чтобы тратить их на бесполезную "защиту"? Поскольку те кто не может "в два клика" сам, могут почти всегда набрать нужную строку поиска в интернете...
Или пример корпораций гигантов (с миллионными установками и пользователями) отказавшихся от проверок собственных приложений на предмет наличия root доступа клиента вам "не пример"? :-)
Т.е. прикладники не в курсе что такое отладчик или думают что их "защиту" сложно обойти парой ассемблерных инструкций? :-) Если прикладную "защиту" еще не сломали - в 90% случаев это значит что ваше "супер приложение" никому и не интересно... Хотя конечно прикладникам никто не мешает думать обратное... :-)
:-) Во многом это зависит от требований и условий... Насколько мне известно данные с датчиков баллистических ракет пишутся напрямую на носитель (без OS и fs). А вот для БД "общего назначения" к примеру та же Oracle от таких "финтов" как запись данных на "сырые устройства" (которой пользовалась множество версий) отказывается... По реальным тестам это давало +5% производительности и +25% "гемороя" администраторам серверов БД....
:-) Это да... Проще посадить ребенка под замок, чем его воспитывать...
Зашибись... Уже учебники и курсы стали в докер оборачивать... :-)
Современные "разработчики" много чего не знают и не умеют... Именно это их заставляет использовать монстрообразные фреймворки которые "еле ползают" на современных многоядерных CPU... Это же проще чем изучать основы и принципы функционирования компьютеров и OS.... :-)
Именно такие "разработчики" пихают в базу "сырые" XML объекты...
"Опыт интернатур" - мало кого интересует (исключая тех кто за это получает себе доход)... Работодателей интересуют готовые специалисты требуемой квалификации... :-) Продавать "золотоискателям" "лопаты" рассказывая "сказки о возможностях скорого заработка"- всегда было выгодно.... :-)
А по вашему "middle+" уже такими рождаются? :-)
Скорее "Полностью прошедший учебник + несколько месяцев интернатуры на реальном проекте будет" = "умею работать по шаблону и инструкции, а чему там нас учили уже не помню..."
Примерно как учебники и курсы из серии - "Как заработать миллион за 3 месяца." :-)
:-) Как то так примерно...
#chown root.root /bin/bash
#chmod 700 /bin/bash
.......
Для .app дать права +rx только пользователю с "нужным" id... У остальных отобрать.
:-) Да уж... Я еще понимаю когда разработчики OS под устройство "защищают" от получения root доступа... Но куда "впрягаются" и "надувают щеки" прикладники то? А главное это абсолютно безуспешно... Но видимо знание базовых принципов прав и разделения доступа в unix - им просто никто нормально не объяснил... :-)
Читая подобные статьи я всегда удивляюсь...
Неужели поколение современных прикладных разработчиков не знает такой простой и давно известной истины, что пользователь с root правами (а jailbreak на IOS как и root на Android именно эти права и позволяют получить) может "скрыть" от любого другого пользователя или программы работающих не от root (а все пользовательские приложения на IOS и Android таких прав не имеют) наличие у себя таких прав или любого приложения/файла на устройстве. Для этого достаточно просто иметь или соответствующие знания OS (в частности unix) или соответствующий сторонний софт (которого так же достаточно, если собственных знаний у вас нет).
Ну ладно законодатели (они "слышали звон, но не знают где он"), но IT то специалисты... Куда же катится уровень знаний современных разработчиков.... :-)
:-) Преимущество будет... Но только тогда, когда QA специалист не просто пройдет один (два или пять) курсов и узнает что такое БД и Linux (по курсам/учебникам типа вашим), а будет разбираться чем работа запросов в Oracle отличается от "аналогичных" в PostgeSQL (или MS SQL), и почему работа одного и того же (к примеру Java) приложения (на одном и том же сервере) в Windows вызывает другую нагрузку на ресурсы сервера чем в Linux, и по какой причине использование 2 серверов с 16 ядрами CPU может быть менее (или более) эффективно чем использование одного сервера с такими же 32 ядрами CPU....
Вот только попытки "впихнуть не впихуемое" в один курс (или учебник) "пробежав по верхам", а после этого заявлять "мы сделали крутую штуку и после ее вы станете крутым профессионалом!", не очень хорошо характеризует уровень знаний его составителей, скорее характеризует их амбиции... :-)
На первый взгляд непосредственно по тестированию не больше половины курса...