@LOLWTF: nie liczyłbym na pudełko z takimi opcjami. Z powodów fundamentalnych. Uwierzytelnienie jest na początku każdego procesu. Dostęp do danego URLa to etap autoryzacji, czyli następny krok. Wymagasz częściowej autoryzacji przed uwierzytelnieniem co oznacza, ze coś tu nie gra.
@LOLWTF: tzn "nie gra" nie oznacza katastrofy, prawdopodobnie masz kilka aplikacji osadzonych w jednej, więc albo je rozdzielisz albo przerobisz tę paczkę do własnych potrzeb, tak by architekturalnie traktowała różne URLe jako różne aplikacje.
@Pipcieo: jest mniej więcej tak, jak mówisz. Mam apkę którą można podzielić na dwa albo i trzy moduły. 1. interfejs webowy 2. moduł łączący się z api serwisu X 3. api wystawione przeze mnie.
punkty 2 i 3 łączą się w jedno, bo po otrzymaniu zapytania na moje api, odpytuję się api serwisu X.
być może lepszym rozwiązaniem byłoby sprawdzenie uprawnień w samym widoku, analogicznie do @login_required
@Pipcieo: wiem. Ale już nie bawmy się w nomenklaturę autoryzacja/uwierzytelnianie. W tej chwili nie wiem, jak ogarnąć validację certyfikatu użytkownika :<
@LOLWTF: z bebechami nie pomogę, bo tej paczki używałem raz (i to nie w django - portowałem). Jaki problem konkretnie - odkrywkowo spróbuję pomóc. Natomiast nie sprowadzaj akurat tego rozróżnienia do nomenklatury bo ten rozdział ma głęboki sens ( ͡º͜ʖ͡º)
@Pipcieo: przeszukałem wujka google i ciocię stack, nie znalazłem nic ciekawego. Możliwe, że źle szukam, że nie podaję jakiegoś słowa-klucza.
Co chcę osiągnąć zabezpieczenie swojego api przed dostępem osób niepowołanych. Dostęp mają mieć tylko ci klienci, którzy dostali ode mnie certyfikat.
Jak do sobie wyobrażam 1. Klient dostaje ode mnie certyfikat (zgaduję, że .p12). 2. Przy wykonywaniu zapytania do mojego api musi powiedzieć "ej, ziom, mam taki certyfikat, wpuścisz?". 3. Sprawdzam,
@LOLWTF: A token nie rozwiązał by problemu? Dajesz klientowi token, ktory jest przypisany do danego usera i przy wywoływaniu api bys spr najpierw token, a potem byś dopuszczał (lub nie) usera.
@LOLWTF: przemyślałem ten temat jeszcze raz i reguła najpierw uwierzytelnienie potem autoryzacja jest tutaj jeszcze silniejsza. Wstępne uwierzytelnienie następuje na poziomie serwera SSL czyli w większości przypadków zanim twoja aplikacja / twój serwer aplikacji dowie się o użytkowniku. To co ten plugin django dostaje to wyłuskane dane z certyfikatu podczas gdy proces pytania o certyfikat został już dawno zakończony. Tak działa SSL, najpierw handshake i wymiana certyfikatów, potem HTTP (GET/POST/whatever) już
#python #ssl #django
Nie chcę ingerować w pozostałą część serwisu i system użytkowników.
Najwyżej wezmę ten kod i napiszę własnego middleware
Uwierzytelnienie jest na początku każdego procesu.
Dostęp do danego URLa to etap autoryzacji, czyli następny krok.
Wymagasz częściowej autoryzacji przed uwierzytelnieniem co oznacza, ze coś tu nie gra.
1. interfejs webowy
2. moduł łączący się z api serwisu X
3. api wystawione przeze mnie.
punkty 2 i 3 łączą się w jedno, bo po otrzymaniu zapytania na moje api, odpytuję się api serwisu X.
być może lepszym rozwiązaniem byłoby sprawdzenie uprawnień w samym widoku, analogicznie do
@login_requiredJaki problem konkretnie - odkrywkowo spróbuję pomóc.
Natomiast nie sprowadzaj akurat tego rozróżnienia do nomenklatury bo ten rozdział ma głęboki sens
( ͡º ͜ʖ͡º)
Co chcę osiągnąć
zabezpieczenie swojego api przed dostępem osób niepowołanych. Dostęp mają mieć tylko ci klienci, którzy dostali ode mnie certyfikat.
Jak do sobie wyobrażam
1. Klient dostaje ode mnie certyfikat (zgaduję, że .p12).
2. Przy wykonywaniu zapytania do mojego api musi powiedzieć "ej, ziom, mam taki certyfikat, wpuścisz?".
3. Sprawdzam,
staram się zrozumieć co nie działa, zamiast tworzyć coś od nowa
@benwatkins: oczywiście, że mógłby rozwiązać. jakieś id + token + zabawy typu HMAC z zapytania i tajnego klucza.
Ale to projekt za hajs unii baluj, więc liczą się mądrze brzmiące słowa-klucze.
Wstępne uwierzytelnienie następuje na poziomie serwera SSL czyli w większości przypadków zanim twoja aplikacja / twój serwer aplikacji dowie się o użytkowniku.
To co ten plugin django dostaje to wyłuskane dane z certyfikatu podczas gdy proces pytania o certyfikat został już dawno zakończony. Tak działa SSL, najpierw handshake i wymiana certyfikatów, potem HTTP (GET/POST/whatever) już
Dzięki wielkie :)