Posts

Showing posts from December, 2018

How to Implement Multiple User Types with Django

Image
Rules of ThumbWhat you are going to read next is not written in a stone. It’s just some general recommendations that fits most cases. If you have a good reason, or if not following those recommendations will result in a better application design, go ahead and break the “rules”! 1. No matter what strategy you pick, or what is your business model, always use one, and only one Django model to handle the authentication.You can still have multiple user types, but generally speaking it’s a bad idea to store authentication information across multiple models/tables. Treat this model as an account rather than a user. Meaning, all users need anaccount to log in. The business logic will be implemented in a different way, so no need to have username/password spread across multiple tables. After all, all accounts should share many common resources such as login, logout, password resets, password change. 2. Never user the built-in Django User model directly, even if the built-in Django User impleme…

CSRF (Cross Site Request Forgery) protection

Cross Site Request Forgery protection is a mechanism of guarding against a particular type of attack, which can occur when a user has not logged out of a web site, and continues to have a valid session. In this circumstance a malicious site may be able to perform actions against the target site, within the context of the logged-in session. To guard against these type of attacks, you need to do two things: Ensure that the 'unsafe' HTTP operations, such as GET, HEAD and OPTIONS cannot be used to alter any server-side state.Ensure that any 'safe' HTTP operations, such as POST, PUT, PATCH and DELETE, always require a valid CSRF token. In order to make AJAX requests, you need to include CSRF token in the HTTP header

CORS (Cross-Origin Resource Sharing)

Image
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application makes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin. An example of a cross-origin request: The frontend JavaScript code for a web application served from http://domain-a.com uses XMLHttpRequest to make a request for http://api.domain-b.com/data.json. For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request HTTP resources from the same origin the application was loaded from, unless the response from the other origin includes the right CORS headers. The CORS mecha…

Cookies and sessions

Cookies and sessions are both ways to preserve the application's state between different requests the browser makes. It's thanks to them that, for instance, you don't need to log in every time you request a page on StackOverflow. Cookies Cookies are small bits of data, (maximum of 4KB long), which hold data in a key=value pairs: name=value; name2=value2 These are set either by JavaScript, or via the server using an HTTP header. Cookies have an expiry datetime set, example using HTTP headers: