Внутренняя аутентификация клиента/сервера API Django или нет?

У меня есть проект django, в котором я показываю несколько конечных точек api (api endpoint = ответы на get/post, возвращает ответ json, исправьте меня, если я ошибаюсь в своем определении). Эти конечные точки используются мной на лицевой стороне, например, подсчитывают количество обновлений или получают обновленный контент или множество других вещей. Я обрабатываю логику представления на стороне сервера, в шаблонах и в некоторых случаях отправляю клиенту визуализированный шаблон строки.Внутренняя аутентификация клиента/сервера API Django или нет?

Так вот вопросы им пытаются ответить:

мне нужно иметь какой-то аутентификации между клиентами и сервером ли?
Является ли django крест происхождения защиты достаточно?
Где на этой фотографии подходят такие пакеты, как django-oauth-toolkit? И django-rest-framework?
Если я не добавляю никакой аутентификации между клиентами и сервером, могу ли я оставить свой сервер открытым для атак?

Кроме того, что же касается соединения «сервер-сервер»? Оба сервера под моим контролем.

источник

2013-12-17 Neara

Если вы спрашиваете - должен ли я реализовать аутентификацию oauth/openid/something для защиты моего сервера от запросов GET, тогда я бы сказал нет. Да, сервер будет открыт, но если ни одно из представлений не позволяет вносить какие-либо изменения в какие-либо объекты, и вы следовали рекомендациям по развертыванию django (http://www.djangobook.com/en/2.0/chapter12.html) то все должно быть хорошо. –

@ OdifYltsaeb да, вот что мне интересно, я должен реализовать oauth или такой для клиентов. Как насчет почтовых звонков? достаточно csrf? А как насчет сервера к серверу? – Neara

Ну, я стараюсь защищать каждый из моих взглядов столько, сколько они требуют. Смысл в том, что у меня есть логин, защищенный большинством просмотров, а для API-интерфейсов обычно требуется ключ API. Таким образом, пока у вас есть ключ API - вы можете делать все, что разрешено: P –

Я бы настоятельно рекомендовал использовать django-tastypie для связи между сервером и клиентом. Я использовал его в многочисленных приложениях как от сервера к серверу, так и от сервера к клиенту. Это позволяет применить защиту django, а также некоторую логику процесса авторизации. Он предлагает также из коробки:

дроссельного
сериализации в JSON, XML и другие форматы
аутентификации (базовая, apikey, индивидуальные и другие)
проверки
авторизации
pagination
кэширование

Итак, в качестве общего обзора я бы предложил построить такую инфраструктуру, которая сделает вашу внутреннюю api более интероперабельной для будущих расширений и более безопасной.

Чтобы конкретно ответить на ваш вопрос, я бы никогда не включил сервер api без хотя бы некоторой базовой аутентификации/авторизации.

Надеюсь, я отвечу на ваши вопросы о том, как вы можете доставить все ваши проблемы выше с помощью рамки.

Основанный на django-rest-каркас, также очень продвинутый и простой в использовании, но я предпочитаю тастипию по причинам, которые я объясняю.

Надеюсь, я немного помог!

источник

2014-01-14 11:30:14

спасибо, это действительно касается моих вопросов. время, чтобы пересмотреть модель моего api. Я все еще удивляюсь, как вы передаете ключ api клиентам, чтобы разоблачить его? и делает ли аутентификация/авторизация клиентов замедлением страницы? – Neara

аутентификация/авторизация не влияет на ответ (в отношении использования стандартного рабочего процесса). Я не понимаю, что вы имеете в виду здесь. «Я все еще удивляюсь, как вы передаете ключ api клиентам, которые подвергли его воздействию». Я был бы рад помочь, поэтому помогите мне разобраться в более глубоком вопросе. Большое спасибо! –

Внутренняя аутентификация клиента/сервера API Django или нет?

ответ

Смежные вопросы