Учетные данные для авторизации удалены - django, elastic beanstalk, oauth


79

Я реализовал REST api в django с django-rest-framework и использовал oauth2 для аутентификации.

Я тестировал:

curl -X POST -d "client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=password&username=YOUR_USERNAME&password=YOUR_PASSWORD" http://localhost:8000/oauth2/access_token/

и

curl -H "Authorization: Bearer <your-access-token>" http://localhost:8000/api/

на localhost с успешными результатами в соответствии с документацией.

При переносе этого на существующий экземпляр эластичного beanstalk AWS я получил:

{ "detail" : "Authentication credentials were not provided." }

6
Ты мой герой. Я потратил на это много часов, но уверен, что вы спасли меня гораздо больше!
Стивен

Вы должны сами ответить на свой вопрос, чтобы он не

1
Я понятия не имею, сколько моего времени это бы ушло, но я почти уверен, что это было бы долго. Спасатель жизни.
Том Мэнтерфилд

Все еще экономит часы и часы в 2020 году
Кайл

Вы сэкономили мне время. Не знаю, сколько дней я действительно не спал всю ночь. Ха ... большое спасибо. Хорошего дня, я очень люблю тебя. Еще экономия часов в июле 2020 года !!!!!!!!!! lol
Тим

Ответы:


30

Сейчас я использую немного другой подход. Решение sahutchi работало до тех пор, пока переменные env не были изменены, как указал Том Дикин. Я немного покопался в EB, выяснил, где находится шаблон wsgi.conf, и добавил туда опцию «WSGIPassAuthorization On».

commands:
  WSGIPassAuthorization:
    command: sed -i.bak '/WSGIScriptAlias/ a WSGIPassAuthorization On' config.py
    cwd: /opt/elasticbeanstalk/hooks

Это всегда будет работать, даже при изменении переменных среды. Надеюсь, вы сочтете это полезным.

Изменить: похоже, что многие люди все еще получают этот ответ. Я давно не использовал ElasticBeanstalk, но хотел бы рассмотреть возможность использования решения Manel Clos ниже. Я не пробовал лично, но кажется более чистым решением. Это буквально взлом скриптов EB, который потенциально может сломаться в будущем, если EB обновит их, особенно если они переместят их в другое место.


Это мило. Теперь, когда у awsebcli есть eb ssh, мне стало легче лениться в dev-ops и выполнять очистку вручную.
sahutchi

3
Все еще актуальный ответ. Хотел добавить, что (как новичок в aws) вы можете просто добавить тег команд в свои файлы .ebextensions .config поверх ваших container_commands, и он будет работать. Подробнее обо всех тегах, которые обрабатываются здесь: ссылка
sean.hudson

С этим связаны две проблемы: 1) работает только при втором и последующих развертываниях, 2) sed продолжает накапливать одну и ту же строку в файле конфигурации каждый раз, когда вы развертываете. Решение Manel Clos (создание нового файла в Apache conf.d) не страдает от этих проблем, и оно также работает при изменении переменных среды.
Майк Плацентра

1
Я давно не использовал EB, но согласен с тем, что его решение чище и элегантнее. Я бы, вероятно, использовал это, если он работает правильно, что должно.
Рубен Дура Тари

Вы спасли выходные моей команде. Большое спасибо!
Атул Мишра

63

Мне нравится идея иметь дополнительную конфигурацию на стандартном месте. В каталоге .ebextensions создайте файл wsgi_custom.config с:

files:
  "/etc/httpd/conf.d/wsgihacks.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      WSGIPassAuthorization On

Как размещено здесь: https://forums.aws.amazon.com/message.jspa?messageID=376244


7
это чистое решение. он работает, когда вы меняете переменные среды, и не добавляет одну и ту же строку в файл конфигурации каждый раз при развертывании.
Майк Плацентра

Получение этой ошибки:not authorized to perform: rds:DescribeDBEngineVersions
Chirag Maliwal

34

Я думал, что проблема связана с моей конфигурацией в django или с каким-либо другим типом ошибки, вместо того, чтобы сосредоточиться на различиях между localhost и EB. Проблема связана с настройками Apache EB.

WSGIPassAuthorization изначально отключен, поэтому его необходимо включить. Это можно сделать в вашем файле * .config в папке .ebextensions, добавив следующую команду:

container_commands:
  01_wsgipass:
    command: 'echo "WSGIPassAuthorization On" >> ../wsgi.conf'

Пожалуйста, дайте мне знать, если я что-то пропустил или есть способ лучше разобраться в проблеме. Я не мог найти ничего конкретно об этом нигде в Интернете и подумал, что это может сэкономить кому-то часы устранения неполадок, а затем чувствовать себя глупо.


5
Кажется, я слишком рано заговорил в своем комментарии выше. Хотя это ДЕЙСТВИТЕЛЬНО работает для первоначального развертывания, если вы что-то измените в своей среде (например, добавите новую переменную), это не будет запускаться при применении этих изменений, и wsgi.conf, похоже, все еще создается заново. Не думаете ли вы о какой-либо конфигурации приложения, которая запускается каждый раз, когда происходит изменение?
Том Мэнтерфилд

Я включаю это в каждый git aws.push. Но да, иногда я теряю css при изменении параметров. Что-нибудь сломается в вашем приложении, если после внесения изменений в среду вы повторно развернете последний push через пользовательский интерфейс в меню «среда - версия приложения»?
sahutchi

Похоже, это исправление устарело. Ответ, занявший второе место от Рубена Дура Тари, работает (если вы исправите опечатку) и на первый взгляд кажется более надежным.
skolsuper

@skolsuper что это за опечатка?
Nate

1
@Nate нет ни одного. Когда я тестировал его, у меня возникла не связанная с этим проблема, которую я нечаянно исправил одновременно с "исправлением" опечатки. Рубен отредактировал свой ответ до рабочего состояния со времен моего шутовства.
skolsuper

0

Хотя приведенное выше решение интересно, есть и другой способ. Сохраните файл конфигурации wsgi.conf VirtualHost, который вы хотите использовать в .ebextensions, и перезапишите его в хуке после развертывания (вы не можете сделать это перед развертыванием, потому что он будет повторно сгенерирован (да, я обнаружил, что это сложный Если вы сделаете это, для перезагрузки обязательно используйте программу supervisorctl для перезапуска, чтобы все переменные среды были установлены правильно (я тоже обнаружил это на собственном горьком опыте).

cp /tmp/wsgi.conf /etc/httpd/conf.d/wsgi.conf
 /usr/local/bin/supervisorctl -c /opt/python/etc/supervisord.conf restart httpd
exit 0

01_python.config:

05_fixwsgiauth:
    command: "cp .ebextensions/wsgi.conf /tmp"
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.