Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Макс, со мной о таких вещах спорить безполезно. "Атаковать могут" — все, это незащищенный софт. Да, он все же еще может быть безопасным, но моя специализация все же защищенность, а не безопасность. А "разве что" и "да и зачем" — это уже из области анализа рисков и совершенно не мое)
Да я и не спорю об этом. Я лишь говорю что веб-приложения на c++ вполне себе писать можно. А будет необходимость защитить, так всё реализуемо, было бы желание и стимул
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Вот тебе кусочек кода НС>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно?
Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода?
S>>В общем ничего там сложного нет, с++ вполне подходит для веб приложений.
KV>Вот только телодвижений для обеспечения защиенности там требуется "слегка" больше (что даже авторы той CMS признают: http://cppcms.com/wikipp/en/page/secure_programming#C.and.C...Security), а профит, который можно получить от использования нативного компилируемого языка, ощутим разве что только в совсем highload-системах
А где там про "больше телодвижений"? Просто перечислен ряд общих рекомендаций, о которые вменяемые программисты и так в курсе и лет 10 как поголовно соблюдают, и пара специфических для веб типа проверки utf-8 на корректность (что, опять же, скорее всего уже делается используемыми библиотеками).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>А где там про "больше телодвижений"?
Отсюда и до конца страницы.
ХГД>Просто перечислен ряд общих рекомендаций
Этот ряд несколько меньше для разработчиков веб-приложений на более традиционных для данной предметной области языках.
ХГД>о которые вменяемые программисты и так в курсе и лет 10 как поголовно соблюдают,
Да, жаль, что все уязвимые приложения были написаны невменяемыми программистами
ХГД>и пара специфических для веб типа проверки utf-8 на корректность
Здравствуйте, Sheridan, Вы писали:
НС>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно? S>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода?
А что в 2014 году еще кому-то нужна вот эта производительность?
Здравствуйте, genre, Вы писали:
НС>>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно? S>>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода? G>А что в 2014 году еще кому-то нужна вот эта производительность?
Да никому не нужна конечно, продолжайте наблюдения.
Здравствуйте, Sheridan, Вы писали:
S>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода?
Понимаешь, какая штука. Допустим, ты где-то слегка ошибся в HTML-коде. Например, написал <a href='/tasks/add'>Саздать задачу</a>. Так вот: исправление такой ошибки может занять пару недель. Потому что ни один вменяемый менеджер проекта никода не выпустит в production версию без полного цикла тестирования. А, как ты говоришь, перекомпиляция — это построение новой версии. Такие дела.
Здравствуйте, Sheridan, Вы писали:
НС>>>>HTML в виде строковых констант в коде? В 2014 году? Че, серьезно? S>>>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода? G>>А что в 2014 году еще кому-то нужна вот эта производительность? S>Да никому не нужна конечно, продолжайте наблюдения.
Есть подозрение, что ты не оценивал производительность, а просто "будет так потому что быстрее". Так?
А поддержка и прочее побоку.
ХГД>>А где там про "больше телодвижений"?
KV>Отсюда и до конца страницы.
Я это внимательно прочитал, ничего про лишние телодвижения там не увидел, кроме разве что проверки корректности utf. Не могли бы вы указать, какие конкретно "лишние телодвижения" там описываются еще?
ХГД>>Просто перечислен ряд общих рекомендаций
KV>Этот ряд несколько меньше для разработчиков веб-приложений на более традиционных для данной предметной области языках.
ХГД>>о которые вменяемые программисты и так в курсе и лет 10 как поголовно соблюдают,
KV>Да, жаль, что все уязвимые приложения были написаны невменяемыми программистами
Уязвимые приложения могут быть написаны и при соблюдении данных рекомендаций, просто уязвимостей будет меньше, чем при несоблюдении. Странно, что вы этого не понимаете. Особенно учитывая, сколько уязвимых веб-приложений написано на более традиционных для данной предметной области языках.
ХГД>>и пара специфических для веб типа проверки utf-8 на корректность
KV>Как корректность UTF-8 связана с вебом? O_o
Чисто статистически — ломать типичное десктопное приложение, подсовывая некорректный utf, мало кому надо (по сравнению, опять же, с вебом).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Privalov, Вы писали:
S>>Всё правильно, упор на производительность. Или в 2014 году есть какая то сложность в компиляции кода?
P>Понимаешь, какая штука. Допустим, ты где-то слегка ошибся в HTML-коде. Например, написал <a href='/tasks/add'>Саздать задачу</a>. Так вот: исправление такой ошибки может занять пару недель. Потому что ни один вменяемый менеджер проекта никода не выпустит в production версию без полного цикла тестирования. А, как ты говоришь, перекомпиляция — это построение новой версии. Такие дела.
Понимаешь, какая штука... На распарсинг шаблона страницы с заменой %переменных%, с разворачиванием циклов (записи, комментарии) и прочей лабудой откусится кусок процессорного времени, который мог бы потратиться на что то полезное, например на генерацию еще одной страницы другому клиенту.
И всё ради того, чтобы проблему "две недели тестирования и после этого в продакшн" переместить от разработчиков к дизайнерам.
Такие дела.
Да, у меня в проекте хтмл генерируется прямо в коде. Что вам мешает сделать по другому, почему мой пример того что на с++ можно писать приложения ставится как пример того что на с++ нельзя писать веб-приложения? Только из за того что необходима компиляция? Это что, такой способ ухода от ответственности — типа "так как компилятор может чего нибудь некрасивого написать и это будет видно перед публикацией в продакшн, то мы откажемся от компилятора и сразу в продакшн"? Или это избавление от "лишних" затрат времени программистов на компиляцию, типа "нам наплевать, пусть клиент берет более мощный сервер"?
Лично я не вижу разницы, тесты нужны как в случае компиляции, так и в случае инрепритации кода. Тесты нужны и дизайнерам на достижение устраивающего всех дизайна.
Или ты о том, что пункты меню надо дать возможность добавлять и править админам приложения? А ты в курсе про байку, в которой говорится что если разработчик не уверен в необходимости/правильности чегототам (поведения, меню, вида), он добавляет новую опцию в настройки?
Или ты о том, что исходники клиенту неохота отдавать? Ну так всякие пэхапэ всё равно отдать придется.
Я понимаю, что разработка действительно крупного проекта обязательно упрётся в подобные препоны между "мы тут написали/поправили" и продакшном, но это препоны скорее административные, чем проблемы выбора языка и архитектуры. Да, придется несколько поменять привычный цикл разработки. Да, продукт выйдет дороже, чем "склепали на пэхапэ". Но я правильно понимаю, что качество и скорость работы превыше всего или современные реалии окончательно требуют отказаться от качества, скорости работы софта и все точки сборки сместились к "быстро пилим, хоп-хоп и в продакшн"?
Здравствуйте, genre, Вы писали:
G>Есть подозрение, что ты не оценивал производительность, а просто "будет так потому что быстрее". Так?
У меня есть еще один проект. В нем я по функционалу я повторяю вордпресс, только без плагинов, тем и прочей лабуды, а пишу сразу то что надо мне. Ну, навскидку: страницы, новости с комментариями, интеграция с соцсетями, галерея медиа. Во всяком случае пытаюсь повторить. Так вот, у меня генерация страницы как минимум на порядок быстрее при том же внешнем виде и функционале.
G>А поддержка и прочее побоку.
Не вижу проблем в поддержке. Если конечно на поддержку не посадить тетю Машу из третьей смены уборщиц.
И вообще, я так понимаю, тут почему то никому не нравится с++. Ну так не ешьте. Были сомнения что веб-приложения на с++ написать нельзя? Я эти сомнения развеял. Что вы еще пытаетесь доказать? Что я как то неправильно пишу? Ну так это мои проблемы, пишите правильно.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Я это внимательно прочитал, ничего про лишние телодвижения там не увидел, кроме разве что проверки корректности utf. Не могли бы вы указать, какие конкретно "лишние телодвижения" там описываются еще? ХГД>Да неужели?
Именно так. Есть конечный ряд угроз, актуальных для веб-приложений, написанных на скриптовых и управляемых языках. При разработке веб-приложения на языках со слабой типизацией и/или поддержкой адресной арифметики и/или возможностью ручного выделения памяти, к этому ряду добавляется еще несколько угроз, связанных с повреждениями стека, кучи, переполнениями численных типов и прочей низкоуровневой радостью.
ХГД>Уязвимые приложения могут быть написаны и при соблюдении данных рекомендаций, просто уязвимостей будет меньше, чем при несоблюдении. Странно, что вы этого не понимаете.
Почему же, вполне понимаю. Как и то, что с ростом числа угроз растет и вероятность допустить ошибку, а следовательно растут и затраты на разработку.
KV>>Как корректность UTF-8 связана с вебом? O_o ХГД>Чисто статистически — ломать типичное десктопное приложение, подсовывая некорректный utf, мало кому надо (по сравнению, опять же, с вебом).
Чисто статистически, проблемы с некорректным юникодом более актуальны для нативных языков и древних версий скриптовых (потому что их интерпретаторы/компиляторы потянули за собой проблемы нативного языка, на котором были разработаны). Я могу придумать сценарий, при котором приложение на управляемом языке будет подвержено каким-либо атакам из-за недостаточной обработки кодировок, но на практике таких сценариев ни я, ни мои коллеги не встречали
Здравствуйте, Sheridan, Вы писали:
S>И вообще, я так понимаю, тут почему то никому не нравится с++. Ну так не ешьте. Были сомнения что веб-приложения на с++ написать нельзя? Я эти сомнения развеял. Что вы еще пытаетесь доказать? Что я как то неправильно пишу? Ну так это мои проблемы, пишите правильно.
А тебе не приходила в голову мысль взять какой-нибудь более подходящий инструмент и к этому моменту запилить раза в два-три больше?
Здравствуйте, Sheridan, Вы писали:
S>Понимаешь, какая штука... На распарсинг шаблона страницы с заменой %переменных%, с разворачиванием циклов (записи, комментарии) и прочей лабудой откусится кусок процессорного времени, который мог бы потратиться на что то полезное, например на генерацию еще одной страницы другому клиенту. S>И всё ради того, чтобы проблему "две недели тестирования и после этого в продакшн" переместить от разработчиков к дизайнерам. S>Такие дела.
Понимаешь, какая штука... Времена, когда процессорное время ценилось выше рабочего времени специалиста, давно и безвозвратно ушли. Другими словами, ни один вменяемый менеджер проекта не даст 2 недели на выпуск версии из-за одной неправильно прописанной буквы. Он предпочтет потратить время работы команды на что-нибудь более полезное. Это значит, что в реальных проектах такого кода, как ты показал, не будет. Собственно, его там и нет. При этом HTML-страницы все еще генерируются автоматически.
Еще давай вспомним, что на доставку HTML-страницы клиенту тратится времени столько, что твоя экономия на тактах процессора перестает быть заметной. Такие дела.
P. S. Когда-то давно ассемблерщики выдвигали против фортранщиков примерно те же аргументы, что ты выдвигаешь против тех, кто работает на языках, отличных от С++ . Но скажи, где сейчас Фортран и где — Ассемблер?
Здравствуйте, genre, Вы писали:
S>>И вообще, я так понимаю, тут почему то никому не нравится с++. Ну так не ешьте. Были сомнения что веб-приложения на с++ написать нельзя? Я эти сомнения развеял. Что вы еще пытаетесь доказать? Что я как то неправильно пишу? Ну так это мои проблемы, пишите правильно.
G>А тебе не приходила в голову мысль взять какой-нибудь более подходящий инструмент и к этому моменту запилить раза в два-три больше?
Мне пришло в голову взять подходящий инструмент и запилить более шустрый проект.
Здравствуйте, Sheridan, Вы писали:
S>Были сомнения что веб-приложения на с++ написать нельзя? Я эти сомнения развеял.
Сомнений в том, что веб-приложения _можно_ писать на любом полным по Тьюрингу языке под рантаймом, умеющим так или иначе работать с сокетами, ни у кого и не было Были сомнения относительно того, _зачем_ это делать? И они, в общем-то, никуда не делись.
ХГД>>Я это внимательно прочитал, ничего про лишние телодвижения там не увидел, кроме разве что проверки корректности utf. Не могли бы вы указать, какие конкретно "лишние телодвижения" там описываются еще? ХГД>>Да неужели?
KV>Именно так. Есть конечный ряд угроз, актуальных для веб-приложений, написанных на скриптовых и управляемых языках. При разработке веб-приложения на языках со слабой типизацией и/или поддержкой адресной арифметики и/или возможностью ручного выделения памяти, к этому ряду добавляется еще несколько угроз, связанных с повреждениями стека, кучи, переполнениями численных типов и прочей низкоуровневой радостью.
Не добавляются, а заменяется — зачем в скриптовых языках в стек гадить, если в них поголовно eval имеется
ХГД>>Уязвимые приложения могут быть написаны и при соблюдении данных рекомендаций, просто уязвимостей будет меньше, чем при несоблюдении. Странно, что вы этого не понимаете.
KV>Почему же, вполне понимаю. Как и то, что с ростом числа угроз растет и вероятность допустить ошибку, а следовательно растут и затраты на разработку.
Ну давай теперь сравним это высказывание с оригинальным утверждением "Да, жаль, что все уязвимые приложения были написаны невменяемыми программистами "
KV>Чисто статистически, проблемы с некорректным юникодом более актуальны для нативных языков и древних версий скриптовых (потому что их интерпретаторы/компиляторы потянули за собой проблемы нативного языка, на котором были разработаны).
Кто и на какой выборке сравнивал?
KV>Я могу придумать сценарий, при котором приложение на управляемом языке будет подвержено каким-либо атакам из-за недостаточной обработки кодировок, но на практике таких сценариев ни я, ни мои коллеги не встречали
Ога, а для нативных приложений, можно подумать, встречали, а не чисто теоретически придумали
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
P>Понимаешь, какая штука... Времена, когда процессорное время ценилось выше рабочего времени специалиста, давно и безвозвратно ушли. Доугими словами, ни один вменяемый менеджер проекта не даст 2 недели на выпуск версии из-за одной неправильно прописанной буквы. Он предпочтет потратить время работы команды на что-нибудь более полезное. Это значит, что в реальных проектах такого кода, как ты показал, не будет. Собственно, его там и нет. При этом HTML-страницы все еще генерируются автоматически.
Слава богам, у меня такого менеджера нет и я могу пилить то что считаю нужным.
P>Еще давай вспомним, что на доставку HTML-страницы клиенту тратится времени столько, что твоя экономия на тактах процессора перестает быть заметной. Такие дела.
Гм. Давай посмотрим.
пэхапэ + шаблоны: получение запроса, парсинг кода, интерпритация, запрос данных в бд, парсинг шаблонов, сборка страницы из "шаблон+данные", передача клиенту.
с++ + инлайн-хтмл: получение запроса, запрос данных в бд, сборка страницы исходя из данных, передача клиенту.
Из этого я вижу укорачивание процесса запрос-результат на три шага, от 7 к 4. Причем уходят именно ресурсоёмкие шаги: парсинг, интерпритация.
Да и вообще, оправдывать тормозной код тем, что все равно "много" времени уйдет на доставку результата как минимум неверно, ибо результат надо доставить в любом случае.
P>P. S. Когда-то давно ассемблерщики выдвигали против фортранщиков примерно те же аргументы, что ты выдвигаешь против тех, кто работает на языках, отличных от С++ . Но скажи, где сейчас Фортран и где — Ассемблер?
Все ушли в с\с++, как более удобный инструмент и при этом практически настолько же шустрый.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Сомнений в том, что веб-приложения _можно_ писать на любом полным по Тьюрингу языке под рантаймом, умеющим так или иначе работать с сокетами, ни у кого и не было Были сомнения относительно того, _зачем_ это делать? И они, в общем-то, никуда не делись.
Вопрос несколько в другой плоскости я поднимаю: а почему бы и нет?
Судя по этим веткам — потому что современные реалии требуют не качественный и быстрый код, а как можно более быстрый и дешевый процесс разработки.
