Основы безопасности веб-приложений

Перфекционизм и бизнес не совместимы в принципе (если их совместить то получится морская свинка, и не морская и не свинья) и мне обидно что это так.

это свидетельствует только о неквалификации программистов, ибо проценты по кредитным программам и другие значения были разбросаны по этому CASE, а не сведены хотя бы в блок констант, я уж и не говорю про базу данных.

Ведь при изменении ставок по кредитной программе приходилось вносить изменения в разные места кода.

Просто есть ряд аксиом промышленного программирования. Основная гласит, что изменения надо вносить один раз и в одно место.

Это то же самое, как если бы Вы использовали CMS в которой код HTML мало того, что зашит в PHP, но для того, чтобы поставить, к примеру, код счетчика на весь сайт, надо его внести в 10 - 15 мест. С удалением ситуация аналогичная :)

Я понимаю, что с точки зрения бизнес - пользователя Вам это без разницы, главное, чтобы картинки на экране правильно показывались... Но, когда за небольшое изменение с Вас требуют уйму дненег, мотивируя это тем, что на такое изменение и его тестирование уйдет десяток человеко-часов, вы задумаетесь, о дальнейшем использовании данной СMS :)

Я знаю конкретный случай, когда банк использовал достаточно дешевую CMS, при том, что каждый квартал на внесение мелких изменений тратились суммы превышающие первоначальную стоимость, и время реакции на запрос о создании раздела составлял в лучшем случае 3 дня.

Для этого есть СУБД (например MySQL) которая собственно для этого и предназначена. К тому же она проста в администрировании (например рнрMyAdmin) да и написать небольшой Front-end для одной таблицы также не составляет труда...

Накрайняк если скрипт стоит на хостинге без MySQL типа www.t35.com то можно занести данные хотя бы в DBF (для правки в Exel) или XML или даже просто TXT (для правки в блокноте) однако было бы странно если бы люди заплатили 300 у.е за скрипт но у них не было бы денег на хостинг...

Из описанного Вами абсолютно не видно чем именно это свидетельствует о неквалификации программистов. О неквалификации это может говорить только в том случае, если в исходном ТЗ было упомянуто несложное изменение этих данных... однако об этом у Вас ни слова.

Или задумаемся следующий раз о более четко поставленном ТЗ на CMS перед исполнителем. Если заказчик не поставил задачу легкого изменения параметров, то исполнитель совершенно не был обязан заморачиваться с реализацией этой задачи, даже наоборот - обязан не заморачиваться... в лучшем случае - предложить заморочиться и поступить так как скажут. Поэтому само по себе 170 case не свидетельствует ни о чем.

Да, есть у некоторых программистов действительно есть манера даже в реализации задачи вида "hello world" накрутить столько ненужных функций, параметров и возможностей, что это выливается и в сроки и в цены неадекватные. Тот самый ненужный заказчику перфекционизм. А дальше уже зависит от квалификации программеров, кто-то будет высмеивать код где не вынесены константы, а кто-то будет высмеивать и тех высмеивальщиков - насмехаясь что они не создали системы где достаточно будет нажать 2 кнопки для синхронизации с системами кредитования всех банков, а просто вынесли данные в константы, ведь это "отнимает каждый раз столько времени для ручного занесения этих данных в константы".

Не раз видели когда ради сайта из 10 страничек, обновляемого по планам раз в год, "программисты" ставили навороченную CMS, при этом падая перед заказчиком под стол глядя на его предыдущий сайт из 9 статичных страничек. Вы считаете это адекватно?

Это как раз иногда по другому может объяснятся, у фирмы в конторе свой сервер, или (в лучшем случае) в ДЦ, и там сидит свой админ со своими представлениями о настройках и нужности для хостинга БД и т.д..

Не путайте аксиому и теорему, первое не требует доказательств !!!

(некоторые люди называющиеся программистами требуют в ТЗ доказывать все аксиомы, но это не делает им чести, скорее наоборот говорит о их лени, и нежелании включить даже 1% своих мозгов)

Фирма это не только "фирма в которой работает от 1000 человек и выше" иногда фирмой называется шарашкина-конторка в которой не то что работу админа но и работу уборщика выполняет "директор" (он же носит гордое название "президент фирмы" и гордится этим)

Не путаем.

Это не единственное свойство аксиомы. Что бы что-то стало аксиомой, недостаточно сказать "это аксиома".

"Константщики" доходят до того, что у них константа число секунд в минуте отдельно описанная, и первое число месяца... "на всякий случай", что бы в коде цифры не писать упаси боже. Если Вы ратуете за это, то нам нечего сказать...

Если что-то в коде по изначальному ТЗ не требует быть переменным и легко изменяемым, то это "waste of time & money" заказчика на реализацию легко изменяемости и переменности этого. Не согласитесь?

И что из этого? Такие фирмы не имеют право на нормальное к ним отношение? Или к чему Вы это?

Зато другие, тоже называющиеся себя программистами, ставят мощную CMS для 10 статических страничек изменяемых раз в год и подсаживают клиента на абонентскую плату по поддержке этой CMS в размере 100уе в месяц. Надо уметь придерживаться золотой середины и главное - требований заказчика.

Это лишь говорит о том что они могут не арендовать сервер а просто пользоваться "шариком", что касается "отношения" то ЛЮБЫЕ КЛИЕНТЫ ОБЯЗАНЫ ПОЛУЧИТЬ ДОЛЖНОЕ ОТНОШЕНИЕ К СЕБЕ (не зависимо от того имеют они свой ДЦ или сидят на "шарике")

Ммм. Мы наверное не смогли пояснить мысль. Не хотят некоторые фирмы пользоваться "3rd-party" хостингом в принципе, вот хоть убейся, и объясняешь, что и лучше будет и дешевле... но ... предпочитают "плохонькое, но свое". Не в цене дело и ни в чем другом, только в этом.

В том то и дело что не все

и он согласен на шарике хоститься.

О чём я и говорю, что даже он заслуживает нормального к себе отношения (лишь бы платил ровно столько сколько указано в контракте, не зависимо от того написано ли там 100 или 100 000) и если он не может себе позволить целый ДЦ это вовсе не значит что надо с него требовать 300 за скрипт который любой студент за бутылку пива напишет !!!

(цены должны быть построены на соотношении обьёма и качества работы, а не на жадности программиста как это делается в 99% случаев)