"процент скопипащеных решений будет уменьшаться" - мне кажется, что со временем процент скопипащенных решений должен только увеличиваться, т.к. понимать написанный код всё-таки быстрее, чем писать свой, нужно только найти его. Но это только со временем.
Петр: Пётр, спасибо. Получилось сделать прототип httpHandler. Информации ооочень мало, примеры все для старого IIS. Самый приличный для IIS 7/8 нашёлся такой: professorweb.ru/my/ASP_NET/base/level4/4_7.php с понятным описанием настроек.
Петр:
Мне нужен фильтр для сайта IIS 8 (на windows 2012 R2 но на D2) ), так что Net очень подходит. Фильтр будет "активироваться" если будет выставлен определённая кука после аутентификации и добавлять ещё одну куку с дополнительной проверкой (там своя кухня в бизнес-логике) и пока вторая кука выставлена, то фильтр работает прозрачно.
Я уже наталкивался на эти классы, но не понял - это тоже самое, что обрабатывать запросы? Просто в IIS обработчики регистрируются на определённые расширения в запросах (как обработчики PHP, например). Я мог бы прописать в качестве расширения "*" или другой wildcard, но правильно ли это?
Вот нашёл один пример: www.codeguru.com/csharp/.net/net_asp/article.php/c... Похож на решение?
И я правильно понимаю, что проект должен генерировать dll?
Виктор Бузин: Спасибо, Виктор, за компонент. Вроде он ничего. Как ни странно, но в другом проекте работа с контролями пошла нормально. Очень странно, если удастся разобраться, то напишу. Генерация при билде меня устраивает.
Спасибо.
К сожалению, CKSDEV для 2013, у меня 2015. Но меня бы устроило пусть даже без designer, но чтобы мои контролы появлялись в файле *.designer.cs (перегенерируемым автоматически), но ведь не хочет:
Там только несколько штук и мне не понятна такая избирательность - эти asp:контролы беру, а другие нет.
Понимаю, что там всякие предупреждения в *.designer.cs, чтобы не править руками, но экспериментировал - руками добавил свой контрол, так нет - стирает всё-таки. Но почему?
xmoonlight: Непосредственно к php fiddler не цепляется, только к компонентам, которые делают http-запросы и через настройки этих компонентов. Надо искать глобальный способ установки proxy для каждого компонента по отдельности, чтобы не задумываться об обфусцированности кода.
xmoonlight: "Есть некий скрипт который шлет во внешний мир запросы через curl".
О приложении я говорю об этом скрипте. Кто инициатор запуска скрипта? Если пользователь делает запрос, php его обрабатывает и в какой-то момент php требуется внешний ресурс, к которому он получает доступ через http-соединение с помощью curl или file_get_content($link), то такое php-приложение является proxy-сервером. Неважно, что оно дополнительно реализует ещё и бизнеслогику.
xmoonlight: Если ваше приложение само генерирует http-запросы при обработке запросов пользователей, то оно является proxy-сервером. Сравните с тем же правилом "обычного" proxy-сервера. Только "обычный" proxy-сервер делает пере-запросы на каждый запрос, а ваше приложение только в определённых случаях, но сути это не меняет. Port-Mirroring - да, это не проксирование, а зеркалирование.
WireShark - да, sniffer,
А вот Fiddler - просто афигенный активный прокси. Если его грамотно настроить, то можно делать всё-что угодно - подменять куки, html-body, подменять целый запросы, врать пользователю всё-что угодно (в отладочных целях, конечно ;) поэтому он так сильно почитаем мною. Но я не хочу поднимать тут холивар, просто wireshark и fiddler немного для разных целей и раз wireshark подошёл, то всё ok. С моей точки зрения fiddler значительно нагляднее, но это imho.
xmoonlight: Ок. Но вы изначально спрашивали про решение с curl. Мне кажется, что проблема с "подглядыванием" за трафиком и в вашем случае и в общем вызвана тем, что ваше приложение по сути само является прокси со своими правилами. А поскольку у каждого php-компонента свой подход к проксированию, то и общего решения нет. К каждому способу проксирования надо подходить покомпонентно и если компонент не умеет проксироваться, то в его случае ничего нельзя будет сделать, в этом суть проксирования.
codercat: В общих чертах да, понятно, но для полноты картины киньте мне на почту парочку-тройку примеров конфигов на почту.
Если у вас названия полей в JSON являются предопределёнными, я бы озаботился отображением и привязкой GUI для некоторых узлов JSON-а. Ну, как пример, что-то типа angular-овского TODO-list, например, к ветке design.main_screen.block_lines, тем более что рисовать иерархические меню на основе JSON у angular "в крови". И так постепенно покрыл бы GUI весь JSON (или его необходимую/минимальную часть/части). А на выходе сделал кнопку "получить json" и пока просто новый json-файл или просто текст.
codercat: Если быть занудой, то у вас написано "на вход он принимает большой json-объект", но про множество конфигов - ни слова. :)
Если вы думаете о переносе этого набора в GUI-интерфейс с базой, то тут придётся помучиться, потому что всплывут те же проблемы, которые есть у всех "веб-клиентов" - разделение доступа, безопасность/аутентификация/авторизация, ведение бд пользователей и всё это не имеет никакого отношения к самой задаче. Если вы рассматриваете вопрос о nosql, то тут есть общая проблема, которая так же не относится к вашей задаче, а решить её придётся - транзакции пока только на уровне одного документа, т.е. если вы решите сохранить два документа и с одним что-то пошло не так, а второй сохранился, то отменить сохранение второго документа и вернуться к исходному состоянию двух документов уже не получится. Вот так "лёгким" внедрением mongo базы в задачу вы получите ворох проблем, решение которых может быть неоправданно дорогим и за которые может и нет смысла браться.
Но это не значит, что ничего не надо делать. Иногда решение находится очень неожиданно и совсем не там где ищете.
