Эээ... а нафига интернет-магазину БД :) ?

Дело не в самописе а в том что вы не знаете броду.

Самопис норм. Не норм когда не хватает опыта. Хороший программист с нуля может решать прикладные задачи в чужой экосистеме, но архитектурные вещи лучше не трогать.

Так то оно понятно что 2/3 сайтов на вордпрессе (по количеству а не по посещалке конечно) легко вскрываемы по вине того кто ставил/настраивал и никого это не парит.

Но все эти сложности есть в бекофисе :) И атаковать будут именно его.

Нет, я понимаю что Security through obscurity на которую вы напираете - имеет место. Но - это пока вы один с одним самописом. А если ваше одноразовое решение пойдет в массы, то такой подход губителен.

Я собственно потому пока и не выкатываю свой фреймворк в опенсорс. Выделить часть функционала в платное а основное отдать в паблик не сложно. Но пока я не провел пару рефакторингов да аудит - Security through obscurity меня немного, но защитит). но повторюсь - это нишевое решение. Для очень узкой ниши.

---------- Добавлено 27.12.2016 в 15:41 ----------

Школьник с парсером это проблема сервера а не движка.

fail2ban спокойно вынесет школьника. Студента вынесет более внятный файрвол.

А от взрослого DDoS мне и с кешированием не защититься без спецсредств.

Вы не подумайте. Конечно "усё будет". Но не сразу.

Я буду сильно переписывать ORM. Связи сильно переколбашу, а значит жадность лучше добавить попозже. Кеширование тоже требует большого внимания. Втулить как в ВП сделано не проблема, но хочется чтобы инвалидация была прозрачной и TTL использовался лишь для чистки кеша, а не как основной инструмент.

Чьерт... годами всё работает без нареканий. Как теперь жить непонятно...

То, что я не специализируюсь на веб-приложениях ничего в общем-то не значит :).

Именно. Но я что-то не верю, что ненаправленная атака что-то даст.

Хотя бесспорно изучу пакетные сканеры уязвимостей... возможно... позже.

Это в добрый путь... понадобится дверь вскрывать полагаю :).

Он как-бы это сказать... по ряду причин в оффлайне почти (впн итп не в счет) :).

Туда попадает только почта, она обрабатывается префильтром довольно жестким,

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

Почтовый сервер отдельно.

Собственно нехай ломают, будет интересно "как", повышу свой уровень.

Да не нужно это никому кроме меня, очевидно-же, что средний заказчик хочет

"свистелок и перделок".

Давайте о секьюрити поговорим. Пока у меня на сервер-сайд 1 php файл на 5кб.

Полагаю если приспичит, то с таким объемом кода "чумовым", я смогу ведь найти

реально хорошего специалиста для аудита. Это если представить меня неким овощем,

который не в состоянии почитать рекомендации для создания форм.

Скажем, за 200 евро.

Или не смогу ? За эти вполне указанные бабки ?

Сколько бабла мне придется вложить в аудит "коробки" в которой понаворотили

на десятки мегабайт :) ? При этом я не верю в то, что везде думали головой.

Я вижу как люди простых вещей не продумали, чего уж тут о секьюрити...

Серьезный DDOS забьет каналы.

Однако вы дело говорите, всегда эту статику можно в S3 выложить... если

критично её функционирование.... Т.е. вы можете любые CDN использовать...

без проблем каких-то.

Т.е. свой сервер выходит нужен только для скрипта чекаута...

Ну это в вашем очень узком кейсе можно сделать связь с сервером очень узкой.

А по 100500 задачам которые озвучили - связь будет более толстой, и тут всё и посыпится.

Я ведь не критикую ваше конкретное решение в вашей конкретной задаче.

Мне вполне себе интересно как оно у вас взлетит.

Я говорю лишь о том, что вопрос в заголовке топика неуместен.

Частный простой случай будет работать хорошо. Но в массе он неприменим.

И возражаем мы в основном к вашему тезису что это универсально, а не частный случай.

Честно говоря опять не очень понимаю о каких задачах речь.

Вам нужно больше информации на клиенте о скидках ?

Загрузите на сервер КОПИЮ информации о скидках.

(в любом тонком виде)

Раздавайте оттуда (1 раз в клиента).

Зачем вы хотите в бэкэнд лазить мне непонятно абсолютно...

Вы хотите считать стоимость доставки ?

Это очень сложный алгоритм, который не может быть реализован

на клиентской стороне ? Зачем он такой вообще :) ?

Идея-то, подчеркну, как-раз в том, чтобы не вкорячивать в интернет-магазин лишнего.

Всего того, что зачем-то вкорячивают в бэкэнд. Что сделано отвратительно.

Чем пользоваться самоубийственно. Что, обычно, уже есть у любого оффлайн-магазина.

Дык в массе ничего другое универсально тоже не применимо.

Или в массе применим коробочный интернет-магазин ?

Много знаете тех, кто не закрылся через 2-3 года с убытками из тех,

кто стартовал с коробки ?

(и много ли из них тех, кто не имел "серебряной пули", к примеру не

являлся дочкой крупного вендера и не имел чумовых скидок и отсрочек платежей )

Впрочем... действительно, я немного забылся, в массе действительно это все

не нужно, т.к. задачи сделать <s>хорошо</s> <s>нормально</s> приемлимо нету,

есть задача получить денег с клиента, показать ему красивые картинки "в админке",

на лету отредактировать его номер телефона (и потом каждый раз его из базы выбирать) итд итп.

ЗЫ. Я допилю где-нибудь "на новогодние", и посмотрим, но т.к. у меня уже есть список фич,

то очевидно, что в моем частном случае работать будет. Вообще печально, что пришлось даже

такой мини-функционал пилить самому - неправильно это. Но вся "индустрия" больна такой

гигантоманией, что уж лучше так.

Ответ по-моему очевиден. Используют стандартную СУБД, чтобы не накручивать свою. Вы ведь по сути над файловой системой надстроите свою СУБД. Зачем? Не понятно. MySQL вообще-то тоже с файлами работает? Что вы нового придумали? Заменили двоичные файлы данных текстовыми (CSV или XML)?

Нет. Он перенес весь функционал в бекофис, а на фронте только статика.

А в бекофисе у него уже СУБД и всё такое :)

Да, именно.

Только давайте расставим акценты иначе.

Я не стал переносить функционал из бэкофиса в интернет-магазин.

Во фронте только статика. В интернет-магазине только статика.

А БД там, где ей место. Там где управление складом, заказами, покупателями итп.

Абсолютно отдельно от интернет-магазина.

А бэкофис в последнем случае уже был давно. Т.к. это был случай разворачивания

интернет-магазина поверх вполне себе "оффлайн-бизнеса".

Вы не слушаете что вам говорят. Совсем.

Вы мешаете в кучу разные вещи и упорно отвечаете на свои же собственные, придуманные вами же возражения.

За шесть страниц обсуждения никто (битрикс не в счет) не сказал что коробка лучше самописа. Никто. Но вы упорно отсылаете всех к коробке. Зачем? Вам так важно быть правым, просто ради того чтобы быть правым? Вы сами создали тему не о коробке, а о том нужна ли БД в магазине. Но тулите везде свои коробки.

У каждого инструмента своя задача. Всякие коробочные Опенкарты - отличное решение чтобы поставить, начать пользоваться, понять вообще что тебе нужно, что не нужно, и наконец внятно написать ТЗ, а изначальный бокс выкинуть, или оставить "как есть" создав новый магаз на новом домене. Я люблю клиентов которые уже хоть немного знают что им надо. Тем кто не знает - пусть пробуют на коробках.

Каждый инструмент решает свою задачу. Вы же ставите инструмент впереди задачи.

Я использую один инструментарий на всех участках - витрина, магазин, бекофис и т.п.

У меня идет готовый фреймворк со своим ORM, шаблонизатором и т.п. Я не хочу как вы тут использовать одно решение, тут шаманить костыли на аякс, тут придумывать как мне считать ваучеры, тут используем пхп, тут не используем, тут у нас база, тут файлы... Я хочу везде использовать одни инструменты. Я хочу решать задачи клиента по мере их поступления. Быстро. Любые. Я не хочу тратить несколько часов на продумывание того как же мне обрабатывать скидочные коды на клиенте потому что я же решил что мне нужно там только статику держать. Надо ли мне солить хеши ваучеров? Как мне их отдать? Да ну их нафиг. При этом я все равно должен всё что надо отразить в бекофисе. У меня все равно должна быть соответствующая таблица. У меня должна быть соответствующая моделька, которая перепроверит правильность заказа еще раз, ведь на клиенте можно все проверки обойти. Вот нафига оно мне?

Инструмент для задачи или задача для инструмента?

Ну ок. Мы помучались и впихнули. у нас есть ваучеры.

Изначальная архитектура их не предусматривала, но не переделывать же всё? Сделали маленький костыль. Прошел месяц. И клиент хочет несколько вариантов логики работы ваучера.

1 - есть товары на которые скидок нет. Совсем.

2 - есть ваучеры "скидка N%",

3 - есть ваучеры "N$ но не более M% от суммы заказа"

4 - есть ваучеры которые одноразовые,

5 - есть ваучеры которые многоразовые, но только одному клиенту,

6 - есть ваучеры многоразовые но "в одни руки один раз",

7 - ну мы еще потом придумаем....

Всё. Приехали. На седьмом пункте приехали. Выходим.

Простой пример. Минутный. Реальный.

Звонит клиент. У них автосалон. ИМ тут конечно весьма условен, но ИМ да.

У них есть форма заказа тестдрайва.

Клиент изначально просил не указывать поле "желаемая машина" потому что по факту у них в салоне не весь ассортимент есть сразу и т.п.

Теперь они захотели чтобы был таки выбор, а манагер потом сам разберется что делать.

Решение?

Открываем файлик модели тест-драйва, добавляем:

Ну и в пхпмайадмин стоит зайти, поле в таблицу добавить.

Предпочитаю на живом проекте делать такие правки ручками.

Всё.

Поле в форме добавилось само.

Селект, варианты, всё такое.

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

Клиенту это не стоит отдельных денег. Задача не требует даже меня дергать. Всё в рамках их абонемента за поддержку (20 баксов в месяц вроде платят). Менеджер сам им добавит.

И да, когда через неделю они захотят добавить к машине атрибут "доступен тестдрайв", красивое отражение этого со ссылкой на форму заказа с уже заполненным полем - ну да, это потребует каких-то телодвижений. Минут 15. Но клиент жЫрный, деньги есть, так что я их буду крутить внаглую разводя на бабло. Я им назову полчаса а не четверть. И не манагера а моих, т.е. возьму 12 баксов. Будет морочить голову с тем как именно красиво оформить кнопочку, несколько вариантов верстки, так вообще час посчитаю). Магазину цветов это будет баксов 5 за "стокове" решение со стандартной кнопкой и стандартной машинкой из фонт-авесом. Сколько это обойдется на вашем велосипеде? Нет, можно. Список вариантов выбора что у вас что у меня генерятся. Ну плюс еще ЖС писать для заполнения формы машинкой из гет.параметров. Но... зачем?

Ну вот вопрос частного случая. Не более)

Сменилась цена товара - генерировать заново кеш

Отсутствие товара - генерировать кеш

Появился новый товар - генерировать кеш

Смена дизайна магазина - генерировать кеш

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

А вот с перелинковкой сложно, хотя при генерации кеша тоже можно.

Итого, кешируются данные не на автомате по мере изменения контента, а по желанию владельца - т.е. пока не нажмет кнопочку и не зальет кеш, магазин будет со старым контентом.