2016-10-20 33 views
7

W mojej dokumentacji API, chciałbym zdefiniować zabezpieczenia niezbędne dla każdego punktu końcowego API. Projekt zdefiniował role i uprawnienia określające, którzy użytkownicy mogą uzyskać dostęp do interfejsów API. Jaki jest najlepszy sposób, aby w Swagger udokumentować te informacje? Czy istnieje najlepsza praktyka lub zalecenie, jak wyświetlić te szczegóły?Jak zdefiniować zabezpieczenia roli/uprawnień w Swagger

To, co wypróbowałem używając securityDefinitions i zdefiniowanej przez siebie zmiennej dla ról, ale ta informacja (x-role-names) nie została skopiowana do dokumentacji, kiedy przeprowadziłem ją przez swagger2markup lub używając swagger- ui.

"securityDefinitions": { 
    "baseUserSecurity": { 
      "type": "basic", 
      "x-role-names": "test" 
     } 
    } 

Jaki jest najlepszy sposób udokumentowania roli i informacji o uprawnieniach na punkt końcowy?

Odpowiedz

2

Jeśli Twój interfejs API wykorzystuje uwierzytelnianie OAuth, można do tego celu użyć zakresów. Nie ma standardowego sposobu reprezentowania ról w Swagger/OpenApi przeciwko podstawowemu uwierzytelnianiu, więc pozostawiasz używanie rozszerzeń dostawców (których narzędzia, takie jak Swagger-UI lub swagger2markup, nie mają możliwości interpretacji, jak odkryłeś) lub włączając informacje jako tekst w ustawieniach summary lub description.

Można zdefiniować wiele różnych typów securityDefinitions i użyć jednego na rolę, ale to trochę hack.

Zobacz także numer wydania https://github.com/OAI/OpenAPI-Specification/issues/1366, aby zapoznać się z propozycją rozszerzenia zakresu stosowania na inne systemy zabezpieczeń.

+0

Widzę opis w specyfikacji, ale nie widzę streszczenia. Która wersja jest dostępna w? Tak czy siak, niestety, te wydają się być wyświetlane tylko w ogólnym bloku bezpieczeństwa, a nie przy każdym wywołaniu API, które byłoby bardziej idealne. Wygląda na to, że określenie swagger2markup z zakresu podstawowego jest dozwolone, ale jest niezgodne ze specyfikacją, więc mogę "zhakować" to, aby było bardziej podobne do nadziei - ale nadal nie jest idealne. – whatsTheDiff

+0

Przepraszam, myślałem o "streszczeniu", a nie "streszczeniu", ale byłby to na poziomie operacyjnym, a nie definicji SecurityDefinition. – MikeRalphson