Obawiam się, że nie ma wiarygodnych sposobów, aby to osiągnąć. Najlepszym sposobem, jaki mogę wymyślić, jest wygenerowanie jakiegoś klucza prywatnego w kliencie javascript i oszołomienie kodu. To by utrudniło "graczowi" korzystanie z twoich metod. Może używając HMAC lub coś w tym stylu.
Przykład. Chcesz wykonać następujące połączenie: /api/users/1/vote_up
. Można mieć pewne kod, aby wygenerować klucz prywatny:
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/hmac-sha256.js">
var hmac = CryptoJS.algo.HMAC.create(CryptoJS.algo.SHA256, generatePassphraseObfuscated());
hmac.update("/api/users/1/vote_up");
var hash = hmac.finalize();
$.ajax(
/api/users/1/vote_up,
{hash: hash}
)
</script>
Funkcja generatePassphraseObfuscated
jest kluczem. Musisz bardzo utrudniać replikowanie. Możesz również zmienić to w każdym żądaniu i dodać plik cookie, aby zidentyfikować, którą "wersję" wysłałeś. Na przykład można mieć dwie wersje:
function generatePassphraseObfuscated(){
return 1;
}
function generatePassphraseObfuscated(){
return 2;
}
i służyć im losowo i identyfikować go z cookie. Więc wiesz, którego użyć w widoku django.
Ponownie, to nie jest niezawodne, nie ma niezawodny sposób robienia tego, co chcesz robić. To po prostu głupi sposób, aby uczynić go brzydkim dla innych ludzi.
jak zamierzasz to nazwać? Wywołanie ajax'a? Lub tylko wewnętrznie, jako usługa internetowa dla własnej aplikacji. – santiagobasulto
@santiagobasulto Jest to połączenie Ajax, nie chcę udostępnić interfejsu API publicznie. Pomysł polega na użyciu tego API tylko za pomocą aplikacji sieciowej, którą buduję. – abhiomkar
Jestem także ciekawy tego i zastanawiam się, dlaczego nie jest powszechne rozszerzanie CSRF, aby to uwzględnić? Lub przynajmniej nie jest to udokumentowane w dokumentach django. Wygląda na to, że wszystkie wywołania AJAX można przełączyć na POST, aby uruchomić ochronę CSRF, ale to wydaje się dość hackowate. – MichaelJones