Лучшие методы, чтобы избежать «очистки данных» из базы данных сайта
Обычно я использую что-то вроде этого, чтобы попытаться поймать все неожиданные исключения верхнего уровня.
using System;
static class Program
{
[STAThread]
static void Main(string[] argv)
{
try
{
AppDomain.CurrentDomain.UnhandledException += (sender,e)
=> FatalExceptionObject(e.ExceptionObject);
Application.ThreadException += (sender,e)
=> FatalExceptionHandler.Handle(e.Exception);
// whatever you need/want here
Application.Run(new MainWindow());
}
catch (Exception huh)
{
FatalExceptionHandler.Handle(huh);
}
}
static void FatalExceptionObject(object exceptionObject) {
var huh = exceptionObject as Exception;
if (huh == null) {
huh = new NotSupportedException(
"Unhandled exception doesn't derive from System.Exception: "
+ exceptionObject.ToString()
);
}
FatalExceptionHandler.Handle(huh);
}
}
Может быть, это то, что вы тоже найдете полезным? Этот основной код маршрутизирует все три способа обнаружения неожиданных исключений верхнего уровня посредством одного вызова метода. Все, что вам теперь нужно, это статический класс FatalExceptionHandler, который включает в себя обработку исключений верхнего уровня в методе Handle.
И действительно, любой разработчик приложений знает, что на самом деле есть только две вещи:
- Показать / записать исключение, как вы видите, подходящее
- Убедитесь, что вы выходите / убиваете процесс приложения
Если вы думаете, что элемент два странных, помните, что мы только потрудились сделать это в первую очередь для действительно исключительных ситуаций. Эти вещи, вероятно, являются ошибками, которые нуждаются в изменениях в вашем приложении, чтобы их можно было точно решить. Любая другая обработка исключений - функциональный вид - должна быть ниже внутри вашего реального программного кода, улавливая определенные виды исключений, если это имеет смысл и обрабатывает их там, как это имеет смысл. Что-нибудь еще должно пузыриться до вашего FatalExceptionHandler, чтобы сделать себя известным и остановить возможную искалеченную программу от работы из поврежденного состояния
Мертвые программы не говорят лжи ...; -)
14 ответов
Если данные опубликованы, они видны и доступны каждому в Интернете. Это включает людей, которых вы хотите видеть, и людей, которых вы не видите.
Вы не можете иметь это в обоих направлениях. Вы можете сделать так, чтобы данные могли быть видны только с учетной записью, и люди будут создавать учетные записи, чтобы украсть данные. Вы можете сделать так, чтобы данные могли быть видны только с утвержденных IP-адресов, и люди пройдут шаги, чтобы получить одобрение, прежде чем отнять их.
Да, вы можете усложнить его получение, но если вы хотите, чтобы это было удобно для обычных пользователей, вам нужно сделать его удобным и для злоумышленников.
принудительно вызывать reCAPTCHA каждые 10 страниц для каждого уникального IP
Используйте тот факт, что скребки имеют тенденцию загружать много страниц в быстрой последовательности, чтобы обнаружить поведение скребков. Отображать CAPTCHA для каждой загрузки n страниц в течение x секунд и / или включать экспоненциально растущую задержку для каждой загрузки страницы, которая становится достаточно большой, когда, скажем, десятки страниц загружаются каждую минуту.
Таким образом, обычные пользователи, вероятно, никогда не увидят вашу CAPTCHA, но скребки быстро достигнут предела, который заставляет их решать CAPTCHA.
Обычно для скрининга приличной суммы нужно делать сотни, тысячи (и более) запросов к вашему серверу. Я предлагаю вам прочитать этот связанный с этим вопрос переполнения стека:
Как вы не позволяете сценаристам хлопать вашим сайтом сотни раз в секунду?
Я не знаю, почему ты это сдерживаешь. Клиент предлагает данные.
Предположительно, они создают ценность каким-то уникальным способом, который нетривиально отражается в данных.
В любом случае.
Вы можете проверить браузер, разрешение экрана и IP-адрес, чтобы узнать, не является ли это каким-то автоматическим скребком.
Большинство вещей, таких как cURL и wget - если их тщательно не настроить - явно не браузеры.
Использование чего-то вроде Adobe Flex - интерфейса приложения Flash - исправит это.
Кроме этого, если вы хотите, чтобы пользователям было легко получить к нему доступ, его легко скопировать.
Мое предложение было бы, что это незаконно в любом случае, так что, по крайней мере, у вас есть возможность обратиться в суд, если кто-то поцарапает сайт. Так что, возможно, лучшее, что можно сделать, - это просто добавить ссылку на оригинальный сайт и позволить людям соскрести. Чем больше они соскребают, тем больше ваших ссылок будет появляться в интернете, создавая все больше и больше страниц.
Люди, которые скребут обычно, не против включения ссылки на оригинальный сайт, поскольку он создает своего рода взаимопонимание с оригинальным автором.
Поэтому я советую спросить своего босса, может ли это быть наилучшим вариантом для здоровья сайта.
Уберите руки от клавиатуры и спросите своего клиента о причине , почему он хочет, чтобы данные были видны, но не могли быть скопированы?
Он просит две несоответствующие вещи и, возможно, обсуждение его рассуждений принесет некоторые плоды.
Возможно, он действительно не хочет, чтобы он был общедоступным, и вам нужно добавить аутентификацию / авторизацию. Или он может решить, что действительно важно открыть API. Но вы не узнаете, пока не спросите.
Нет простого решения для этого. Если данные доступны публично, их можно удалить. Единственное, что вы можете сделать, это усложнить жизнь скребку, сделав каждую запись немного уникальной, добавив / изменив HTML, не затрагивая макет. Это может затруднить сбор данных с использованием регулярных выражений, но это все еще не является реальным решением, и я бы сказал, что любой, кто достаточно решителен, найдет способ с этим справиться.
Я хотел бы предложить вашему клиенту, что это недостижимая задача, и приступить к выполнению важных частей вашей работы.
Попробуйте использовать Flash или Silverlight для своего интерфейса.
Хотя это не может остановить кого-то, если он действительно решителен, это будет сложнее. Если вы загружаете свои данные через сервисы, вы всегда можете использовать безопасное соединение, чтобы предотвратить сглаживание посредников.
Вы действительно ничего не можете сделать. Вы можете попытаться найти автоматизированный процесс, проходящий через ваш сайт, но в итоге они победят.
Эмпирическое правило: если вы хотите что-то сохранить для себя, держите это в Интернете.
Как насчет создания чего-то, похожего на защиту троллей на доске объявлений ... Если обнаружена очистка (возможно, определенное количество обращений в минуту с одного IP-адреса или направленный обход, похожий на обход карты сайта), вы можете затем начать представлять данные мусора, например, изменить пару цифр телефонного номера или добавить глупые имена в поля имен.
Отключите это для IP-адресов Google!
Есть несколько способов сделать это, хотя ни один из них не идеален.
-
Представлять данные в виде изображения вместо HTML. Это требует дополнительной обработки на стороне сервера, но это не составит труда с графическими библиотеками в PHP. В качестве альтернативы, вы можете сделать это только для запросов определенного размера (то есть всего).
-
Загрузить оболочку страницы, затем извлечь данные с помощью вызова AJAX и вставить их в DOM. Используйте сеансы для установки хэша, который должен быть передан обратно с вызовом AJAX для проверки. Хеш будет действителен только в течение определенного промежутка времени (то есть 10 секунд). Это на самом деле просто добавление дополнительного шага, через который кто-то должен был бы перепрыгнуть, чтобы получить данные, но это предотвратило бы простой просмотр страницы.
Несмотря на то, что ничто не мешает определенному человеку очищать общедоступный контент, вы можете сделать несколько основных вещей, чтобы смягчить опасения клиента:
-
Ограничение скорости по учетной записи пользователя, IP-адресу , пользовательский агент и т.д. Если вы обнаружите большой объем передаваемых данных, вы закроете учетную запись или IP-адрес.
-
Требуется JavaScript - чтобы гарантировать, что клиент имеет некоторое сходство с интерактивным браузером, а не пауком-босиком ...
-
RIA - сделать ваши данные доступными через интерфейс насыщенного интернет-приложения. Сетки на основе JavaScript включают в себя ExtJ, YUI, Dojo и т. Д. Более богатые среды включают Flash и Silverlight, как 1kevgriff упоминает .
-
Кодировать данные как изображения. Это довольно навязчиво для обычных пользователей, но вы могли бы закодировать некоторые из ваших таблиц данных или значений в виде изображений, а не текста, что могло бы победить большинство текстовых анализаторов, но, конечно, не надежно.
-
robots.txt - для запрета явных веб-пауков, известных агентов-пользователей роботов.
User-agent: *
Disallow: /
-
Использовать метатеги роботов. Это остановило бы пауков. Это не позволит Google проиндексировать вас, например:
< meta name = "robots" content = "noindex, follow, noarchive" >
Существуют разные уровни сдерживания и первый вариант, вероятно, наименее навязчивый.