Django view security and best-practices
I've recently begun working on Django and now my app is nearing completion and i've begun to wonder about security and best-practices.
I have view that generates a page and different functions in the page post AJAX requests to individual views. For example, I have a view called show_employees and I can delete and update employees by passing an an post request to the views delete_employee and update_employee.
I've put @login_required decorators before each of these views since I don't want anyone accessing them without being authenticated. Is this okay?
In the delete_employee and update_employee views, I only respond to request if it is an AJAX POST request (uisng is_ajax()). Is this okay?
I return a 'success' when the view succeeds in doing what is needed and an error when there is a Validation error in my form but I'm still not handling other exceptions. How should I do this? Should i return standard 500 page through an AJAX response like this by wrapping the view with a try-except block to handle all exceptions?
Is there anything else I can do secure my view?
Here's a sample view of mine:
@login_required
def add_site(request):
data = {}
if request.method == 'POST':
if request.is_ajax():
form = AddSiteForm(request.user, request.POST)
if form.is_valid():
site = form.save(commit=False)
site.user = request.user
site.save()
data['status'] = 'success'
data['html'] = render_to_string('site.html', locals(), context_instanc开发者_开发百科e=RequestContext(request))
return HttpResponse(simplejson.dumps(data), mimetype='application/json')
else:
data['status'] = 'error'
data['errors'] = {}
for field, error in form.errors.iteritems():
data['errors']['id_'+field] = strip_tags(unicode(error))
return HttpResponse(simplejson.dumps(data), mimetype='application/json')
Thank you.
Well, instead of only using @login_required, I suggest you take a look at the permissions framework and the associated permission required decorator. This way you can fine tune access restrictions on a user or group basis. It's also easier and safer to change user behavior afterwards with permissions than with just a login_required decorator. Suppose now you have only admins, but later you want to add other kinds of users, it's easy then to miss a login_required decorator then and granting those users access to admin views. You won't have this problem with properly defined permissions.
Next, is_ajax just checks for the HTTP_X_REQUESTED_WITH header. This has not really to do with security, but with user friendly behavior. This way you prevent a normal user from accidentally opening that page in the browser and getting some weird data. It does not help anything in security, every decent hacker can set an additional HTTP header :).
Not handling exceptions can be potentially dangerous, if you accidentally leave on the DEBUG=True
, in which case django will provide pieces of code and backtraces, potentially giving away weaknesses. But, if this option is off django will show it's own 500 error page. My suggestion is: look for all expected django exceptions (aren't that many) and make sure you catch those properly. Further I'd say, let the other exception be handled by django, django will still provide possibilities to generate backtraces and other debugging info and send these to the admins instead of displaying them on-site. If you catch all unexpected errors this behavior will not be directly available, maybe leaving you unknown about failing code.
Finally, as you are working with user input data, I'd suggest you take a look at the security chapter in the django book, it explains the most important threats and how to handle them in the django framework.
精彩评论