zappa niestandardowy autoryzator do kolby z corsami

Question

Używam kolb-cors dla aws python aws lambda API. Zrobiłem to z zappa, działało zgodnie z przeznaczeniem. Jeszcze Cors nie działa z niestandardowym Autoryzatora zainspirowany https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/blob/master/blueprints/python/api-gateway-authorizer-python.py

Zmieniłem kod Autoryzatora z try/z wyjątkiem i wygenerować politykę metody OPTION wyjątku nadal metoda Opcja zwraca 401.

mi nie przeszkadza obejść, jeśli to ułatwia sprawę.

Dzięki

Próbowałem jednym z proponowanych rozwiązań: To ustawienie nagłówków dla 401 odpowiedzi w API Gateway, z żalem inspekcji wstępnej przeglądarka oczekuje udanego kod stanu.

Answer 1

Ten API Gateway problem (który został potwierdzony przez ludzi AWS) istnieje od miesięcy.

Na szczęście ostatnio (czerwiec 2017 r.) Opublikował sposób na naprawienie go za pomocą Gateway Responses.

---

W swojej konsoli API bramy, przejdź do API i następnie Odpowiedzi bramy.

Look dla Unauthorized (401) i dodaj następujące nagłówki (można użyć domen, oczywiście):

Access-Control-Allow-Headers: '*' 
Access-Control-Allow-Origin: '*' 

patrz obrazek poniżej:

Answer 2

• Uzyskanie 401 z Twojej metody OPTIONS w Bramie API jest bardzo nietypowe . Widzę 403 s i brakuje nagłówków CORS na OPTIONS połączeń całkiem sporo, ale generalnie nie 401. Jeśli wystąpił problem z twoim authorizer, oczekiwałbym 401 na następującym POST, a nie na wywołaniu OPTIONS.

• Wspomniał Pan także, że zmieniał kod autoryzatora w wysiłku , aby poradzić sobie z tym.

Nie widząc konfiguracji twojej bramki API, nie mogę powiedzieć tego na pewno, ale te dwa punkty wskazują na możliwość. To brzmi jak Twój autoryzowany autor może być podłączony do twojej metody OPTIONS (oprócz POST lub cokolwiek próbujesz odsłonić). Tak nie powinno być.

Na przykład, jeśli dołączyć niestandardowy (typ) żeton Autoryzatora do metody z API bramy zasobu OPTIONS, a następnie dokonać OPTIONS połączenia bez nagłówka Authorization, dostaniesz się 401.

Autoryzator niestandardowy powinien być dołączany tylko do metod, które jawnie ujawniasz.W wielu przypadkach jest to po prostu POST, ale może obejmować inne, takie jak PUT, DELETE i tak dalej.

Jeśli nie jest to pomocne, możesz zaktualizować pytanie za pomocą konfiguracji bramy API, a także nagłówków żądania/odpowiedzi z niedziałającego połączenia .

UPDATE

I wdrożył aplikację HelloWorld kolby przy użyciu Zappa i myślę, że udało mi się odtworzyć problem. Używam planu, z którym się łączysz, do niestandardowego autoryzatora. Zmiana policy.denyAllMethods() na policy.allowAllMethods() była jedyną zmianą, jaką do niej wprowadziłem.

Kiedy wdrożyć, coś w tym jest tworzony:

udało mi się dostać 401 z OPTIONS połączenia, które nie zawierało Authorization nagłówek.

dodałem "cors": true do mojego zappa_settings, który stworzył coś znacznie więcej CORS friendly:

Ta konfiguracja wygląda lepiej. Koniec z 401 z OPTIONS, niezależnie od tego, czy nagłówek Authorization jest obecny, czy nie.

My zappa_settings z "cors": true dodanych wygląda następująco:

{ 
    "dev": { 
     "app_function": "hello.app", 
     "aws_region": "us-east-1", 
     "profile_name": null, 
     "project_name": "flask", 
     "runtime": "python3.6", 
     "s3_bucket": "zappa-xxxxxxxxx", 
     "cors": true 
    }, 
    "authorizer": { 
    "arn": "arn:aws:lambda:us-east-1:xxxxxxxxxxx:function:flask-authorizer", 
    "result_ttl": 0 
    } 
}