[GlenPL]

Mirki, jest sobie backend w django wystawiający REST api. Korzystać z niego mają frontend webowy, aplikacja na ios i aplikacja na androida. Nie ma systemu userów - żeby korzystać z serwisu nie trzeba być użytkownikiem. Czy jest jakiś sposób w jaki można uniemożliwić lub znacznie utrudnić korzystanie z tego api klientom innym niż te 3 wymienione wcześniej?
#programowanie #django #python #rest

[toshibaas]

@GlenPL: albo dorobić generowanie kont klienta albo jakiś HASH pomiędzy aplikacją, a backendem w sensie generowanym na podstawie np. czasu itd. . Zablokować bez logowania w pełni tego nie zablokujesz ale utrudnisz.

[GlenPL]

@toshibaas: no właśnie kłopot jest z tym frontendem webowym, bo tam każdy może podejrzeć sobie autentykację ( ͡° ʖ̯ ͡°)

[toshibaas]

@GlenPL: Jeśli nie będzie kont klientów to w żaden sposób tego nie zabezpieczysz bo aplikacja wykorzystuje tylko połączenie do jakiegoś backendu i tylko i wyłącznie to, a w milion sposobów można to za-symulować.

[s.....r]

@GlenPL: jest jeden niezawodny sposób ( ͡° ͜ʖ ͡°)ﾉ⌐■-■

[GlenPL]

@toshibaas: tak właśnie czułem ( ͡° ʖ̯ ͡°) jakby taki hash miał działać? Zasymulowanie go czy obsługiwanie go identycznie jak przeglądarka też się wydaje śmiesznie proste, a kryterium jest takie, że może być do obejścia - ale ma być upierdliwe. Pewnie głupie pytanie, nie dałoby się tego zrobić CORS+klucze dla aplikacji ios/android?

@shar: serwis ma być dostępny publicznie dla ludzi bez logowania i niczego

[toshibaas]

@GlenPL: możesz wysyłać specjalny HEADER dla każdej z aplikacji..dodatkowo będziesz wiedział która aplikacja jaki ruch generuje.

[GlenPL]

@toshibaas: tylko taki header też można łatwo spoofować :(

[morsik]

tylko taki header też można łatwo spoofować :(

@GlenPL: to musisz dodać certyfikat SSL z certificate pinning tak by aplikacja kliencka odmówiła połączenia gdy ma inny (np. fake'owy cert). No ale to się odnosi do Androida i iOS… w przeglądarce tak łatwo tego nie zrobisz (głównie Google to ma w swoim Chrome i też nie łatwo chyba się dodać na tę listę).

Inaczej… no cóż. Wszystko da się obejść. Zresztą. Logowanie też

[drwxr]

@GlenPL: mówiłem ci

[GlenPL]

Jaki problem Ci robi używanie tego API? Po to ono jest by z niego korzystać

@morsik: api jest dla komunikacji frontu z backendem, a nie po to, żeby ktoś stworzył swoją stronkę/aplikację/cokolwiek z niego korzystającą :)

frontend nie może być JavaScriptowym

[morsik]

@morsik: api jest dla komunikacji frontu z backendem, a nie po to, żeby ktoś stworzył swoją stronkę/aplikację/cokolwiek z niego korzystającą :)

@GlenPL: jeśli robisz to publicznie przez JavaScript to z definicji jest własnie po to. Czy tego chcesz czy nie :P

Tak jak napisałem. Musisz wywalić JS i zrobić webówkę w części od Django, bez JavaScriptu który na tacy podaje wszelkie możliwe zapytania.

[GlenPL]

@morsik: api jest z DRF a nie czystego django, a to w czym jest frontend nie zależy ode mnie :)

[morsik]

a to w czym jest frontend nie zależy ode mnie

@GlenPL: tak to jest jak prace zlecają ludzie którzy nie mają pojęcia o tym co zlecają… ( ͡° ʖ̯ ͡°)

Na takie coś jedyna odpowiedź brzmi

[GlenPL]

@morsik: dołączyłem do projektu kilka dni temu, w django też jestem świeży


więc mam tyle pokory, żeby jeszcze nie krytykować innych/klienta :)

Nie

[morsik]

( ͡° ʖ̯ ͡°)

@GlenPL: JS to tak bardzo bliski uzytkownikowi frontend, że ciężko wymyślić mi sposób nawet na utrudnienie tego… wystarczy odpalić Firebuga czy innego Web Inspectora i zobaczyć jakie robi requesty. Jedyne co mi przychodzi do głowy, to zmiana API co godzinę, żeby uprzykrzyć życie :D
Ale to jest tak głupie i chamskie, że posypie się po pierwszej godzinie jak gdzieś się strona nie odświeży albo użytkownik zostawi przeglądarkę

[GlenPL]

@morsik: moim zadaniem jest właśnie powiedzieć im, że jest to niemożliwe :)

JS to tak bardzo bliski uzytkownikowi frontend, że ciężko wymyślić mi sposób nawet na utrudnienie tego

Mi też, ale liczyłem, że jakoś jednak się da ( ͡° ͜ʖ ͡°)

Wielkie dzięki za wkład, duży plus dla Ciebie ++