Было бы гораздо интеснее если бы можно было через command line parameters передать, а так получается что надо несколько версий файла проекта держать. Или их чем-то автоматически править. Это не отличается от правки исходного кода или помены одного cs файла на разные версии при сборке.
Так его бы и без валидация во фронтенде точно так же бы нашли.
Как бы вы нашли, если у вас логи валидации были бы забиты валидными срабатываниями пользователей которые просто неправильные данные ввели. Как вы их отфильтруете.
Это каким конкретно образом она вдруг так идёт?
Очень просто идёт. Большинство валидаций, это что параметр необходим, что это число или дата или что максимальная длина не больше той что база принимает или что долен быть валидный емайл и т.п.
насчет нагибать — это безосновательное утверждение от слова совсем.
Получается что баг нашли, польза на лицо.
Зато двойная валидация — это отличный способ удорожить разработку и удорожить поддержку
Во-первых в 90% случаев двойная валидация идёт бесплатно и автоматом. Во-вторых надо как-то пользователю показывать что, что-то не так как должно быть, если гонять данные на сервер и обратно для каждого валидирования, пользователи начнут кричать как-же web 2.0, хочу как у больших пацанов.
Его фронтенд-действий для защиты от того, что актуально для бекенда, заведомо будет недостаточно.
Ну например для того чтобы если мы отвалидировали всё правильно на фронтенде, то на сервере дублирующая валидация должна быть чистой. Если она сработала, то это red flag и кто-то нас пытается нагибать.
Вопрос лишь в том, насколько глубоко надо копать.
Копать нужно до глубины использования технологий на проекте. Если глубже, то это начинаются красно-чёрные алгоритмы Нагла или треугольные люки в пределе к x.
А смысл, если бекенду всё равно надо это всё валидировать?
Я не писал что надо валидировать. Вы говорите что нету смысла фронтенд девелоперу знать потенциальные security vulnerabilities? т.е. работая с фронтендом и встретив ссылки типа /account/openfile?filename=../../mydata.txt он должен сказать, ну и ок, я же фронтенд, это не моё. Мне главное из джаваскритпа XSS не замутить.
К вашему серверу могут обращаться далеко не только из написанного фронтендером, э, фронтенда.
Именно, это как раз показывает что человек понимает что вообще потенциально может происходить и получает плюсик при разговоре. Проблема с тем что если кто-то изучил основные вопросы для прохождения интервью, но не имеет реального знания в написаннии систем, хоть какого-то уровня важности, это всё вскрывается обсуждением реального, плохого кода.
Ну и теоретизирование в том что такой подход не работает, разбивается о нашу практику его использования (не претендую на истинную-истину).
Никто не жаловался, а что-то я не пойму в чём контекст, наоборот говорили что гораздо меньше стресса от чтения кода, чем от написания или алгоритмирования. К тому же спросить и прояснить непонятные детали, очень легко. Показывает общий уровень воспреимчивости к нечётким требованиям.
Только вот с «using» там вроде бы всё не так радужно.
В самом коде его нету, если кому-то хочется сказать что «Представьте себе, что вы компилятор» по поводу «using», то как бы ожидается что он хотя бы погуглил что это за зверь, ну и не использование «using» это вполне нормально и как раз повод для разговора.
Но не «третий момент»? :)
Может и третий. Там было «если у него общие представления о хорошести кода совпадут с вашими» так что постеснялся по мелочам придираться.
На сколько я помню, FileStream есть и в node.js и в java, я думал что «var fs = new FileStream» в качестве примера это настолько просто, насколько возможно.
Ну и у меня например первый вопрос который возник при взгляде на ваш код был а почему «d:\data\» не запихнуто в какую-то константу.
Опять же, хороший подовод поговорить. Если человек спросит про что-то подобное, это плюс. Если вместо константы предложит получать значение из конфигурационного файла, еще лучше.
В чём заключается моё самоутверждение? И как вы в буковках на экране видете обиду.
Извините великодушно, последний раз имел дело с потрохами вебсервера в 2008 году.
Вы хоть погуглите для смеха что это такое, фронтенд девелопер должен относиться к безопасности своего приложения как к приоритету.
вы бы без труда припомнили бы свои варианты ситуации, когда плохо запроектированные и ужасно именованные публичные API живут годами, потому что менять их очень дорого.
Опять же, вы не понимаете про что идёт разговор. Имя параметра filename это не проблема, проблема в том, что вы считаете что это является проблемой.
Контекст как бы существует по позиции на которую собеседуется человек.
Потом, в моём комментарии я говорил о куске кода где-то в двадцать строк, этого достаточно для понятия контекста.
Ну и тем более если фронтенд девелопер, начинает трактовать два слова Request и QueryString как-либо кроме получения значения параметра из query string, это звоночек посильнее всех трёх вместе взятых. Говорит о том что он вообще не понимает что такое query string. Это уже клиника (для фронендера).
Если же он задаст вопрос
валидируется или авторизируется значения из Request.QueryString
то это как раз тот разговор который я ожидаю. Сразу понятно что человек мыслит в каком-то направлении и понимает процессы происходящие (или могущие происходить) на более низком уровне.
И вполне допускаю что мое мнение не правильное, за что заслуженно получил пару минусов в карму.
Я поделился опытом, который _может быть_ полезен начинающему интревьюеру, привел пример и в благодарность был облит помоями от человека который потом сам говорит — ну я же в этом ничего не понимаю, что вы от меня хотите.
Но вот ваш ответ, с другой стороны, очень хорошо иллюстрирует мой начальный тезис об необходимости самоутвердиться за счёт кого-то еще.
Наоборот, это ваш ответ подтверждает правильность методики интервьюирования.
Одна строчка кода выявила три проблемы. Одну общую и две технических.
1. Общая и наиболее важная — не зная C# и осозновая это, вы же незамедлительно бросаетесь судь о чём либо с высоты своего невежества. И после этого оправдываетесь отсутсвием знаний. Это характеризует вас как человека с «душком».
Нормальный человек хотя бы сначала спросил про что вообще речь идёт, вы же сразу начинаете поливать собеседника известной субстанцией.
2. directory traversal это базовая концепция и к C# не имеет отношения. Судя же по вашему ответу вы не имеете понятия что это вообще такое.
3. Поверх этого, вы начинаете рассуждать о проблеме с именованием параметра filename, т.е. вы серьёзно обсуждаете использование анти-паттерна «security through obscurity», что добавляет ещё один штришок к общей картине.
В целом я бы порекомендовал вашему работодателю отправить вас на курсы повышения квалификации. Хотя для джуна, это вполне простительно, не сразу Москва строилась.
var fs = new FileStream(@"d:\data\" + Request.QueryString["filename"]);
Здесь два момента — отсутствие «using» и directory traversal.
Одна строчка, а разговора может минут на десять, чтобы ответить что? почему? как надо?
Подобного всего строк двадцать, но большиство распространнённых ошибок присутствует.
А вы мне рассказываете про ошибки компилятора и «итого вместо того, чтоб действительно проверять технические навыки кандидата, вы, как и обычно, проверяете принадлежность кандидата к «своим»».
Я написал что мы это использовали много раз и результат превосходит альтернативные методы по качеству и временным затратам. Как для нас, так и для собеседующихся.
Он не в других живёт, просто есть некоторая часть иммигрантов, которые чуть-чуть тронулись (ну или были тронутыми) и новая страна для них это как новая религия. Неофиты стараются быть святее чем папа римский и подмахивают даже когда их никто не просит.
Если вы сами проводите интервью, то уверяю вас, вы должны были увидеть столько случаев попыток пролезть на позицию повыше, что трудно чему либо удивиться.
Разговор за жизнь, это хорошо, но должна быть техническая состовляющая. Я например привожу кусок легаси кода где сделаны все возможные ошибки и прошу объяснить что сделано неправильно, почему и как поправить.
Никаких сортировок, круглых люков, тестовых заданий и т.п., но работает как магия. Через пять минут видно если человек имеет представление от том что он видит.
Я поучавствовал в нескольких аджайл и «аджайл» проектах, _лично_ мне и аджайл и «аджайл» нравиться больше чем водопады.
Один аджайл был очень хорош, но там заслуга менеджера, который сам тянул и как результат всё случалось, вне зависимости от методологии.
Также нравятся короткий горизонт планирования. Нравилась концепция харденинг спринтов. Правильная система управления задачами.
Не нравились стендапы, если команда человек 6-8, то толку почти нету. Либо это вырождается в обсуждение деталей специфичных проблем конкретного человека, либо трешовый, никому не нужный формализм без ценности для участников. Позволяет менеджеру не работать с джирой и иметь иллюзию контроля. Для команды 2-3 человека выглядит как профанация и так все всё знают.
Не нравились ретроспективы, первые пару раз прикольно, потом ощущение дня сурка.
Покеры планирования и нравились и нет. С одной стороны некоторый отдых от рутины, с другой дикая трата времени, хотя полезно для тех кто не очень тянет.
В целом, если ты даже чуть-чуть лучше коллег, то аджайл тебе позволяет показать себя во всей красе (за их счёт).
Но как методология, _лично мне_ видится, что это попытка управления проектами с неудовлетворительным и некомпетентным менеджментом. Ну и психологическая методика, выдоить программистов посуше.
Очень просто идёт. Большинство валидаций, это что параметр необходим, что это число или дата или что максимальная длина не больше той что база принимает или что долен быть валидный емайл и т.п.
Для aps.mvc что-то типа
В .net forms это достигается тем что валидатор на форме автоматом делает это за вас.
Для валидаций в ангуляре, можно автоматически сгенирировать правила валидирования базируясь на определнии модели с сервера.
Ну и теоретизирование в том что такой подход не работает, разбивается о нашу практику его использования (не претендую на истинную-истину).
Никто не жаловался, а что-то я не пойму в чём контекст, наоборот говорили что гораздо меньше стресса от чтения кода, чем от написания или алгоритмирования. К тому же спросить и прояснить непонятные детали, очень легко. Показывает общий уровень воспреимчивости к нечётким требованиям.
Опять же, хороший подовод поговорить. Если человек спросит про что-то подобное, это плюс. Если вместо константы предложит получать значение из конфигурационного файла, еще лучше.
Вы хоть погуглите для смеха что это такое, фронтенд девелопер должен относиться к безопасности своего приложения как к приоритету.Опять же, вы не понимаете про что идёт разговор. Имя параметра filename это не проблема, проблема в том, что вы считаете что это является проблемой.
Потом, в моём комментарии я говорил о куске кода где-то в двадцать строк, этого достаточно для понятия контекста.
Ну и тем более если фронтенд девелопер, начинает трактовать два слова Request и QueryString как-либо кроме получения значения параметра из query string, это звоночек посильнее всех трёх вместе взятых. Говорит о том что он вообще не понимает что такое query string. Это уже клиника (для фронендера).
Если же он задаст вопрос то это как раз тот разговор который я ожидаю. Сразу понятно что человек мыслит в каком-то направлении и понимает процессы происходящие (или могущие происходить) на более низком уровне.
И вполне допускаю что мое мнение не правильное, за что заслуженно получил пару минусов в карму.
Я поделился опытом, который _может быть_ полезен начинающему интревьюеру, привел пример и в благодарность был облит помоями от человека который потом сам говорит — ну я же в этом ничего не понимаю, что вы от меня хотите.
Одна строчка кода выявила три проблемы. Одну общую и две технических.
1. Общая и наиболее важная — не зная C# и осозновая это, вы же незамедлительно бросаетесь судь о чём либо с высоты своего невежества. И после этого оправдываетесь отсутсвием знаний. Это характеризует вас как человека с «душком».
Нормальный человек хотя бы сначала спросил про что вообще речь идёт, вы же сразу начинаете поливать собеседника известной субстанцией.
2. directory traversal это базовая концепция и к C# не имеет отношения. Судя же по вашему ответу вы не имеете понятия что это вообще такое.
3. Поверх этого, вы начинаете рассуждать о проблеме с именованием параметра filename, т.е. вы серьёзно обсуждаете использование анти-паттерна «security through obscurity», что добавляет ещё один штришок к общей картине.
В целом я бы порекомендовал вашему работодателю отправить вас на курсы повышения квалификации. Хотя для джуна, это вполне простительно, не сразу Москва строилась.
Вы конечно будете говорить я C# не знаю, я фронтендер, моё дело аттрибуты цвета выставлять. Ну вот и выставляйте.
Здесь два момента — отсутствие «using» и directory traversal.
Одна строчка, а разговора может минут на десять, чтобы ответить что? почему? как надо?
Подобного всего строк двадцать, но большиство распространнённых ошибок присутствует.
А вы мне рассказываете про ошибки компилятора и «итого вместо того, чтоб действительно проверять технические навыки кандидата, вы, как и обычно, проверяете принадлежность кандидата к «своим»».
Я написал что мы это использовали много раз и результат превосходит альтернативные методы по качеству и временным затратам. Как для нас, так и для собеседующихся.
Разговор за жизнь, это хорошо, но должна быть техническая состовляющая. Я например привожу кусок легаси кода где сделаны все возможные ошибки и прошу объяснить что сделано неправильно, почему и как поправить.
Никаких сортировок, круглых люков, тестовых заданий и т.п., но работает как магия. Через пять минут видно если человек имеет представление от том что он видит.
Один аджайл был очень хорош, но там заслуга менеджера, который сам тянул и как результат всё случалось, вне зависимости от методологии.
Также нравятся короткий горизонт планирования. Нравилась концепция харденинг спринтов. Правильная система управления задачами.
Не нравились стендапы, если команда человек 6-8, то толку почти нету. Либо это вырождается в обсуждение деталей специфичных проблем конкретного человека, либо трешовый, никому не нужный формализм без ценности для участников. Позволяет менеджеру не работать с джирой и иметь иллюзию контроля. Для команды 2-3 человека выглядит как профанация и так все всё знают.
Не нравились ретроспективы, первые пару раз прикольно, потом ощущение дня сурка.
Покеры планирования и нравились и нет. С одной стороны некоторый отдых от рутины, с другой дикая трата времени, хотя полезно для тех кто не очень тянет.
В целом, если ты даже чуть-чуть лучше коллег, то аджайл тебе позволяет показать себя во всей красе (за их счёт).
Но как методология, _лично мне_ видится, что это попытка управления проектами с неудовлетворительным и некомпетентным менеджментом. Ну и психологическая методика, выдоить программистов посуше.