Ajax только доступ
Вы уверены, что это - узкое место? Вы сделали какой-либо анализ производительности?
Попытка с помощью профилировщика NetBeans (его свободное и встроенный в NB 6.1) для рассмотрения горячих точек.
Наконец, обновление JVM (говорят от 1.5-> 1.6) часто является дешевым усилителем производительности. Даже обновление в номере сборки может обеспечить хорошие повышения производительности. Если Вы работаете на Windows, и это - приложение класса сервера, используйте - сервер на командной строке для использования JVM Горячей точки Сервера. На машинах Linux и Соляриса это автоматически обнаруживается.
5 ответов
Вы не можете надежно предотвратить это. Ключ на самом деле состоит в том, чтобы не рассматривать кого-либо, напрямую обращающийся к этому файлу, как проблему безопасности - спланируйте это возможным, и вы окажетесь в гораздо более безопасном месте.
Некоторые люди могут порекомендовать код, который выглядит примерно так (или похожий):
if(!empty($_SERVER['HTTP_X_REQUESTED_WITH'])
&& strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
// more code here
}
Однако суть в том, что заголовки HTTP можно довольно легко подделать, и они не являются средством защиты кода. Некоторое время назад при тестировании на загруженном сайте я заметил, что эти заголовки в любом случае не так надежны.
Как уже говорили другие люди в своих ответах, это невозможно. Это связано с одним из основных принципов компьютерной безопасности: нельзя доверять клиенту. Вот почему мы проверяем весь ввод от клиента и т. Д.
Вместо того, чтобы пытаться заблокировать доступ других клиентов к вашим службам, вместо этого тратите время на написание защитных веб-служб. Это означает, что необходимо убедиться, что злоумышленники не могут проскочить инъекции или другие атаки через вашу бизнес-логику. Например, убедитесь, что все электронные письма действительны, люди не покупают товары за отрицательные деньги и т. Д.
Да, и тот факт, что веб-службы открыты, - ХОРОШО! Вы предоставляете своим пользователям открытый API, что очень удобно! Возможно, вместо того, чтобы пытаться заблокировать свое сообщество, вы примете его - дайте им некоторую документацию о том, как взаимодействовать с вашими услугами, и они сделают больше клиентов. Вместо того, чтобы покупать iPhone SDK и тратить время на изучение цели C, может один из ваших пользователей.
Используйте сеансы в вашем приложении.
Редактирование:
Зарегистрируйте свой сайт в сеансе, я использую для этого UUID.
Установите cookie с тем же значением, которое вы использовать в сеансе.
Отправьте свой AJAX-запрос с параметром, который также включает это значение.
Сравните значения из сеанса, файла cookie и параметра.
Нет способа напрямую запретить доступ. Поскольку запрос всегда можно создать в соответствии с любыми критериями, которые вы придумали.
Если XmlHttpRequest используется для запроса сервера, он добавляет заголовок, который можно обнаружить, используя что-то вроде:
/* AJAX check */
if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
//Do something here
}
Возможно, вам стоит использовать какую-нибудь технику защиты от XSS, например, передать какой-то защищенный ключ вместе с запросом ajax. И дайте ключ только тому javascript, который выполняет асинхронные запросы вместе с загруженной страницей.
<script type="text/javascript">
window.csrf_key = '<?php $user->getCsrf(); ?>';
</script>
В этом случае вам не придется беспокоиться о том, что люди передают запросы к файлам напрямую, только если вы храните ключи в безопасности, используйте POST для вызова действий и проверки работоспособности.