Comments 13
UFO just landed and posted this here
Как раз сегодня запилили такую фичу в Web-клиенте — возможность исключить security-sensitive информацию из репорта ещё из до отправки его на сервер. См. файл, свойства IgnoreFormFields, IgnoreHeaders, IgnoreCookies, IgnoreServerVariables. Через запятую задаются маски имён ключей, которые на сервер отправлять не надо.
0
Антивирусы не паникуют при работе вашего логера? Периодически на тематических форумах вижу жалобы, что хукеры воспринимаются, как вирус.
+2
Все возможные антивирусы не проверяли. Те что в наличии есть — не паникуют. По логике вещей и не должны бы, т.к. приложение установило хуки самостоятельно, при помощи кода из подписанной dll-ки, явно прописанной в зависимостях. Т.е. сборка вполне легально попала в процесс.
Более того, антивири не ругались даже в тех случаях, когда сборка в процесс внедрялась гораздо более противоестественным образом. Делал такое для техподдержки, для тех случаев, когда клиент по различным причинам не может или не хочет пересобирать/перевыкладывать приложение только ради включения в него крэш-репортера. А подробная информация о падении критично важна для воспроизведения и фикса.
Более того, антивири не ругались даже в тех случаях, когда сборка в процесс внедрялась гораздо более противоестественным образом. Делал такое для техподдержки, для тех случаев, когда клиент по различным причинам не может или не хочет пересобирать/перевыкладывать приложение только ради включения в него крэш-репортера. А подробная информация о падении критично важна для воспроизведения и фикса.
0
Если проверять код сборки сканером по сигнатурам CWE, то можно получить примерно такое предупреждение: «В коде найдено использование хуков. Проверьте, что ничего противоправного этот код не делает». Не антивирус, конечно, но для полноты картины.
+1
По моему опыту, большая часть проблем возникает из-за данных, которые приложение обрабатывает. Чаще всего это данные получены из файла или из удаленного сервиса в сети, а не введены пользователем вручную. В этом случае, знание о том, куда пользователь ткнул и что нажал, мало поможет. Имхо лучше собирать логи и потом во время падения пытаться определить нужный набор логозаписей (т.е. относящихся к проблеме) и их уже отправлять?
0
«Мы зачастую строим здания, которые склонны рушиться. Для решения этой проблемы увеличим скорость вращения Земли, чтобы вес объектов на её поверхности снизился...»
+5
Может стоило бы вместо словарика использовать `ThreadLocal`, который бы проследил сам, что айдишки потоков все правильные, да и использовать удобнее.
+1
С использованием ThreadStatic/TLS проблематично сделать вот такую тотальную зачистку хуков:
protected void RemoveHooks() {
lock (hooks) {
foreach (int threadId in hooks.Keys)
UninstallHook(threadId, hooks[threadId]);
hooks.Clear();
}
}
0
Почему нет?
protected void RemoveHooks() {
lock (hooks) {
foreach (var hook in hooks.Values)
UninstallHook(hook);
}
}
https://msdn.microsoft.com/en-us/library/hh194898(v=vs.110).aspx
С другой стороны, повторно повесить их уже не получится. Но ведь хуки логирования должны висеть всё время работы приложения, так что это не проблема, они никогда не удаляются.
+1
Sign up to leave a comment.
Оно само упало, или следствие ведут колобки