masnun, Author at Abu Ashraf Masnun

Django REST Framework & AngularJS $resource – Trailing Slash Problem

If you use ngResource ($resource) from AngularJS, you probably have already noticed that AngularJS removes the trailing slash from an URL. Django, on the other hand by default has “APPEND_SLASH” turned on. So when you request:

http://example.com/api/object

Django redirects you to:

http://example.com/api/object/

Yes, Django adds an extra slash to the URL. Django REST framework also follows this scheme. Every api end point has a trailing slash.

Angular, not having any trailing slash will always request the first URL above and get redirected to the second one. Apart from the cost of one extra http request, this is fine. The pain appears when we want to make POST request. Django can’t redirect POST requests and won’t accept POST data on the URL without a slash at the end. Damn, Our AngularJS app breaks because it can’t make request to the URL Django expects!

This is a very annoying and known bug with an open issue on their Github for quite sometimes. Since the latest version doesn’t yet have it fixed, I was stuck. Then I noticed somewhere that Django REST Framework responds to this particular bug allowing an extra parameter to “DefaultRouter” to create API endpoints without any trailing slash. Just do this –

api_router = routers.DefaultRouter(trailing_slash=False)

1	api_router = routers.DefaultRouter(trailing_slash=False)

It will make sure that the API urls don’t have any slash at the end and play nice with Angular. But we’re not done yet, Django will still try to redirect requests appending a slash. Let’s fix this by adding this to the main settings.py:

APPEND_SLASH = False

1	APPEND_SLASH = False

Now, we should be able to make REST calls using AngularJS and $resource with sanity! 🙂

Django REST Framework, AngularJS and SessionAuthentication

Here’s the scenario, I am working on an application that uses Django REST Framework in the backend. On the front end I use AngularJS with ngResource. The application is expected to have a web front end and mobile applications in the future. So I chose both BasicAuthentication and SessionAuthentication as default authentication options. BasicAuthentication uses the basic HTTP Auth to verify the user and is suitable for mobile devices. And SessionAuthentication uses the default Django session. Since I have a web front end, SessionAuth comes very handy – I don’t need to send auth data on every request if the user is logged in already.

This works excellent for GET or HEAD requests but things get rough when you need to make a POST, PUT or DELETE request. SessionAuthentication depends on the CSRF token mechanism built into Django. Django requires a special header to be sent with the csrf token. Details are on the Django docs – https://docs.djangoproject.com/en/1.5/ref/contrib/csrf/#ajax.

Getting the cookie and parsing the csrf token part is rather simple. I ported the jQuery version to a generic JavaScript version just by replacing jQuery.trim() with String.prototype.trim() –

function getCookie(name) {
    var cookieValue = null;
    if (document.cookie && document.cookie != '') {
        var cookies = document.cookie.split(';');
        for (var i = 0; i < cookies.length; i++) {
            var cookie = cookies[i].trim();
            // Does this cookie string begin with the name we want?
            if (cookie.substring(0, name.length + 1) == (name + '=')) {
                cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                break;
            }
        }
    }
    return cookieValue;
}

function getCookie(name) {

var cookieValue = null;

if (document.cookie && document.cookie != '') {

var cookies = document.cookie.split(';');

for (var i = 0; i < cookies.length; i++) {

var cookie = cookies[i].trim();

// Does this cookie string begin with the name we want?

if (cookie.substring(0, name.length + 1) == (name + '=')) {

cookieValue = decodeURIComponent(cookie.substring(name.length + 1));

break;

}

return cookieValue;

}

Now, ngResource or $resource isn’t very customizable compared to the $http component and most people suggested me to use the latter. Just when I was about to lose hope and planning to rewrite my own wrappers around $http, I just came to realize that $resource is also based on $http. If I can change the global $http config to push the header, $resource will also use the same header. So, I configured things like this –

var service = angular.module("apiService", ["ngResource", "ui.bootstrap"]);

service.config(["$httpProvider",
    function (provider) {
        provider.defaults.headers.post["X-CSRFToken"] = getCookie('csrftoken');
    }
]);

var service = angular.module("apiService", ["ngResource", "ui.bootstrap"]);

service.config(["$httpProvider",

function (provider) {

provider.defaults.headers.post["X-CSRFToken"] = getCookie('csrftoken');

}

]);

And finally it works! 😀 Now, every POST request made using $http will have that extra header. But I don’t mind since my application is probably not going to make POST requests to any alien servers 🙂

Recent Posts

Recent Comments

Archives

Categories