#java #javascript #jquery #ajax #spring-security
#java #javascript #jquery #ajax #spring-безопасность
Вопрос:
Привет, я работаю над приложением на Java, поскольку это серверный язык, а на стороне клиента я использую Ajax. Но я довольно новичок в приложениях ajax, поэтому мне понадобилось несколько мнений по проблеме, с которой я столкнулся. Я использую Spring Security для своих служб аутентификации и авторизации, и, читая форумы Spring, мне удалось интегрировать Spring Security с приложением Ajax таким образом, что запросы ajax могут перехватываться и предприниматься соответствующие действия. Вот в чем проблема: каков наилучший способ сообщить приложению ajax о том, что на сервере произошла ошибка. Что я делал до сих пор, так это то, что по соглашению я делаю случайные ошибки http 500 . например, для запроса входа в систему я возвращаю 550 и 551 для другой проблемы и так далее. Но я думаю, что это неправильный подход к этому. Каков наилучший подход к решению этой ситуации?
Комментарии:
1. Во всех ответах в основном говорилось одно и то же. Большое спасибо.
Ответ №1:
Если стандартные коды ошибок HTTP (например, 401 Unauthorized) достаточно обширны, используйте их. Лучше не придумывать свои собственные коды ошибок HTTP, они предназначены для исправления. Если вам нужно вернуть больше информации, вы должны вернуть более богатый объект в теле ответа (сериализованный, например, как JSON или XML) и проанализировать объект на стороне клиента.
Комментарии:
1. При проверке w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 , похоже, коды ошибок HTTP являются расширяемыми, поэтому вы могли бы использовать диапазон 4xx. Но более стандартно возвращать информацию о приложении в теле ответа.
Ответ №2:
По моему опыту, создание собственных кодов ошибок HTTP — не лучший подход.
-
Я знаю стеки HTTP-протоколов на стороне клиента и сервера, которые обрабатывают нестандартные коды состояния HTTP как ошибки протокола.
-
Нестандартный код, вероятно, приведет к появлению запутанных сообщений об ошибках, если они в конечном итоге будут обрабатываться как ответы, отличные от AJAX.
Аналогично, использование части ответа «фраза причины» может быть проблематичным. Некоторые серверные стеки не позволяют вам установить его, а некоторые клиентские стеки отбрасывают его.
Мой предпочтительный способ сообщать об ошибках в ответ на запрос AJAX — отправить стандартный код (например, 400
— BAD REQUEST) с телом ответа XML, JSON или обычным текстом, в котором содержится подробная информация об ошибке. (Обязательно установите заголовок типа содержимого ответа …)
Ответ №3:
Если это ошибка в вашем приложении или взлом, от которого вы хотите защититься, просто верните общую ошибку доступа. Не сообщайте подробно об ошибке на клиенте, поскольку это может быть использовано хакером, чтобы лучше понять, как злоупотреблять вашим API. В любом случае это сбило бы с толку обычных пользователей.
Если это должно быть нормальным поведением приложения, возможно, было бы лучше убедиться, что вы допустили корректный сбой, разрешив повторить попытку позже (если это сработает), переподключиться или пройти повторную проверку подлинности. Вы должны, по крайней мере, распознать, является ли это ошибкой отключения или ошибкой с недостаточными правами, и отобразить пользователю приятное объяснение.