In Django Rest framework, we can verify permissions such as (isAuthenticated, isAdminUser...)
but how can we add our custom permissions and decide what django can do with those permissions?
I really want to understand what happens behind (I didn't find a documentation that explaint this):
#permission_classes([IsAdminUser])
Thank you
Write your own permissions, like this:
def permission_valid_token(func):
# first arg is the viewset, second is the request
def wrapper(*args, **kwargs):
valid_token, user_token = test_token_authorization(args[1].headers) # my function to validate the user
if not valid_token:
return Response(status=status.HTTP_401_UNAUTHORIZED)
return func(*args, **kwargs)
return wrapper
This is a permission that i'm using in app, probably you will have to change the valid_token part
And them you import in your views
from file_that_you_use.permissions import permission_valid_token
And you use as a decorator
class WeatherViewSet(viewsets.ViewSet):
#permission_valid_token
def list(self, request):
This is just a viewset for example, you can use generic viewsets or whatever you want.
If you are using VSCode, hover over #permission_classes([IsAdminUser]), click on Command (on your keyboard).
You can see what happens behind the scenes, play and create your custom Django version (not recommended) or you can overwrite the function.
Related
I want to use the default PasswordChangeView to change passwords for users in a project. The problem is that by default it works for the current user. Is it possible to use the view with a custom user, i.e. provided in the URL?
# this doesn't work by default
url(r'users/(?P<user_id>\d+)/change_password/$',
PasswordChangeView.as_view()
name="password-change")
I think that PasswordChangeView is designed to change the password of a user that is already logged in. Then you have to create a view that inheritance from PasswordChangeView and override the method get_form_kwargs like this:
class _PasswordChangeView(PasswordChangeView):
def get_form_kwargs(self):
kwargs = super().get_form_kwargs()
kwargs['user'] = User.objects.get(id=1) # or any, or get id from url
return kwargs
Be sure of add some permissions to this view, for security reasons. By the way the django admin have this option already.
I'm using flask security to authenticate users. I've made sure the authentication works properly with the http_auth_required decorator - the user is being validated against the userstore (an SQLAlchemyUserDatastore in my case), and all is well.
I would like now to use my own authentication method (I'll be using a custom LDAP validation system), while still taking advantage of the things Flask-Security is giving me (things like current_user). I wrote a custom decorator that looks like this:
def authenticate_with_ldap(func):
#wraps(func)
def wrapper(*args, **kwargs):
if not request.authorization:
return unauthorized_user_handler()
user = user_datastore.get_user(request.authorization.username)
if not user or not authenticate_with_ldap(user.email, user.password):
return unauthorized_user_handler()
return func(*args, **kwargs)
return wrapper
However, when I look at the http_auth_required decorator I see that it uses a private function called _check_http_auth that is doing some stuff that I can't do on my own without accessing private members, like setting the user to the top of the request context stack and sending signals. The code looks like this:
def _check_http_auth():
auth = request.authorization or BasicAuth(username=None, password=None)
user = _security.datastore.find_user(email=auth.username)
if user and utils.verify_and_update_password(auth.password, user):
_security.datastore.commit()
app = current_app._get_current_object()
_request_ctx_stack.top.user = user
identity_changed.send(app, identity=Identity(user.id))
return True
return False
So my question is: what is the correct way to have a custom authentication method, while still utilizing Flask-Security to its fullest?
You can accomplish this with a quick monkey patch. Not ideal, but I'm not sure what else you can do until the Flask-Security team writes in a more elegant way to handle this.
import flask_security
def verify_and_update_password_custom(password, user):
return user.verify_password(password)
flask_security.forms.verify_and_update_password = verify_and_update_password_custom
I'm not sure if it is used anywhere else. The above works for my own purposes. If it does get called elsewhere, you would just need to monkeypatch it into place wherever that is.
I want to prevent logged-in users to access login and register forms.
I've build custom mixin, but it isn't working. The problem is that even if the user is logged in, he can access login and register forms instead of beeing redirected to homepage.
My Mixin
class MustBeAnonymousMixin(object):
''' Only anonymous users (not logged in) may access login and register
'''
def dispath(self, *args, **kwargs):
if not self.request.user.is_anonymous:
return redirect(reverse('homepage'))
return super(MustBeAnonymousMixin, self).dispatch(*args, **kwargs)
LoginFormView
class LoginFormView(MustBeAnonymousMixin, TemplateView):
'''
Display basic user login form
'''
template_name = 'members/login.html'
def get_context_data(self, **kwargs):
context = super(LoginFormView, self).get_context_data(**kwargs)
context['login_form'] = UserLoginForm()
return context
I'm using Django 1.8. What am I doing wrong?
For another case where mixin does not work:
Remember: "Mixin param" must stand before "GenericView param"
Correct:
class PostDelete(LoginRequiredMixin, generic.DeleteView):
Incorrect:
class PostDelete(generic.DeleteView, LoginRequiredMixin):
Fix the typo in dispath and use is_authenticated() instead of is_anonymous (as indicated in the previous answer already)
is_anonymous should be a function call, and you probably should not use it:
is_anonymous()
Always returns False. This is a way of differentiating User and
AnonymousUser objects. Generally, you should prefer using is_authenticated() to this method.
I have a project with several apps, each having its own database. I have a working routers.py to specify the correct database to use for each model. One of the app uses the django-admin subsite to manage its models.
This was all working fine in Django 1.5, but when moving to Django 1.6, I am not anymore able to edit my models: When I access the edit page of a model, I am getting an error "[SQL Server Native Client 11.0]Login timeout expired".
After some investigation, it seems like Django tries to connect to the database default which contains only dummy data in this project, as it should not be used anywhere.
Why does Django try to connect to the default database in 1.6, whereas it was working fine in 1.5? How can I fix this issue in 1.6?
[EDIT]
After some more research, I have found that Django uses the decorator #transaction.atomic for a few functions of its class ModelAdmin.
Looking at the code of this decorator, it seems like it's intended to support the possibility of specifying the database alias that needs to be used for this atomic transaction, with #transaction.atomic(using), and otherwise, if just called with #transaction.atomic as it is in the ModelAdmin Django class, it will use the DEFAULT_DB_ALIAS defined in django.db.utils.
I have tried unsuccessfully to override this behaviour and make these functions use the database alias I want.
Would you know of any way to do this?
I have finally found a way to force Django admin to use the database I want, but it's really hacky. If someone comes with a better solution, please do post it.
I have created a file named admin_helper.py where I redefine the methods that use the #transaction.atomic decorator in Django codebase, with exactly the same content, and using the decorator #transaction.atomic(DATABASE_ALIAS) which tells Django to use the correct database:
DATABASE_ALIAS = 'alias_of_the_database_i_want_to_use'
class ModelAdminCustom(admin.ModelAdmin):
#csrf_protect_m
#transaction.atomic(DATABASE_ALIAS)
def add_view(self, request, form_url='', extra_context=None):
# exact same content as the method defined in django.contrib.admin.options.ModelAdmin
#csrf_protect_m
#transaction.atomic(DATABASE_ALIAS)
def change_view(self, request, object_id, form_url='', extra_context=None):
# exact same content as the method defined in django.contrib.admin.options.ModelAdmin
#csrf_protect_m
#transaction.atomic(DATABASE_ALIAS)
def delete_view(self, request, object_id, extra_context=None):
# exact same content as the method defined in django.contrib.admin.options.ModelAdmin
class MultiDBUserAdmin(UserAdmin):
#sensitive_post_parameters_m
#csrf_protect_m
#transaction.atomic(DATABASE_ALIAS)
def add_view(self, request, form_url='', extra_context=None):
# exact same content as the method defined in django.contrib.auth.admin.UserAdmin
# Unregister existing instance of UserAdmin for the User model, and register my own
try:
admin.site.unregister(User)
finally:
admin.site.register(User, MultiDBUserAdmin)
Then in my normal admin.py:
from myapp.admin_helper import ModelAdminCustom
class MyModelAdmin(ModelAdminCustom):
pass
admin.site.register(MyModel, MyModelAdmin)
I'm new to the web development world, to Django, and to applications that require securing the URL from users that change the foo/bar/pk to access other user data.
Is there a way to prevent this? Or is there a built-in way to prevent this from happening in Django?
E.g.:
foo/bar/22 can be changed to foo/bar/14 and exposes past users data.
I have read the answers to several questions about this topic and I have had little luck in an answer that can clearly and coherently explain this and the approach to prevent this. I don't know a ton about this so I don't know how to word this question to investigate it properly. Please explain this to me like I'm 5.
There are a few ways you can achieve this:
If you have the concept of login, just restrict the URL to:
/foo/bar/
and in the code, user=request.user and display data only for the logged in user.
Another way would be:
/foo/bar/{{request.user.id}}/
and in the view:
def myview(request, id):
if id != request.user.id:
HttpResponseForbidden('You cannot view what is not yours') #Or however you want to handle this
You could even write a middleware that would redirect the user to their page /foo/bar/userid - or to the login page if not logged in.
I'd recommend using django-guardian if you'd like to control per-object access. Here's how it would look after configuring the settings and installing it (this is from django-guardian's docs):
>>> from django.contrib.auth.models import User
>>> boss = User.objects.create(username='Big Boss')
>>> joe = User.objects.create(username='joe')
>>> task = Task.objects.create(summary='Some job', content='', reported_by=boss)
>>> joe.has_perm('view_task', task)
False
If you'd prefer not to use an external library, there's also ways to do it in Django's views.
Here's how that might look:
from django.http import HttpResponseForbidden
from .models import Bar
def view_bar(request, pk):
bar = Bar.objects.get(pk=pk)
if not bar.user == request.user:
return HttpResponseForbidden("You can't view this Bar.")
# The rest of the view goes here...
Just check that the object retrieved by the primary key belongs to the requesting user. In the view this would be
if some_object.user == request.user:
...
This requires that the model representing the object has a reference to the User model.
In my project, for several models/tables, a user should only be able to see data that he/she entered, and not data that other users entered. For these models/tables, there is a user column.
In the list view, that is easy enough to implement, just filter the query set passed to the list view for model.user = loggged_id.user.
But for the detail/update/delete views, seeing the PK up there in the URL, it is conceivable that user could edit the PK in the URL and access another user's row/data.
I'm using Django's built in class based views.
The views with PK in the URL already have the LoginRequiredMixin, but that does not stop a user from changing the PK in the URL.
My solution: "Does Logged In User Own This Row Mixin"
(DoesLoggedInUserOwnThisRowMixin) -- override the get_object method and test there.
from django.core.exceptions import PermissionDenied
class DoesLoggedInUserOwnThisRowMixin(object):
def get_object(self):
'''only allow owner (or superuser) to access the table row'''
obj = super(DoesLoggedInUserOwnThisRowMixin, self).get_object()
if self.request.user.is_superuser:
pass
elif obj.iUser != self.request.user:
raise PermissionDenied(
"Permission Denied -- that's not your record!")
return obj
Voila!
Just put the mixin on the view class definition line after LoginRequiredMixin, and with a 403.html template that outputs the message, you are good to go.
In django, the currently logged in user is available in your views as the property user of the request object.
The idea is to filter your models by the logged in user first, and then if there are any results only show those results.
If the user is trying to access an object that doesn't belong to them, don't show the object.
One way to take care of all of that is to use the get_object_or_404 shortcut function, which will raise a 404 error if an object that matches the given parameters is not found.
Using this, we can just pass the primary key and the current logged in user to this method, if it returns an object, that means the primary key belongs to this user, otherwise it will return a 404 as if the page doesn't exist.
Its quite simple to plug it into your view:
from django.shortcuts import get_object_or_404, render
from .models import YourModel
def some_view(request, pk=None):
obj = get_object_or_404(YourModel, pk=pk, user=request.user)
return render(request, 'details.html', {'object': obj})
Now, if the user tries to access a link with a pk that doesn't belong to them, a 404 is raised.
You're going to want to look into user authentication and authorization, which are both supplied by [Django's Auth package] (https://docs.djangoproject.com/en/4.0/topics/auth/) . There's a big difference between the two things, as well.
Authentication is making sure someone is who they say they are. Think, logging in. You get someone to entire their user name and password to prove they are the owner of the account.
Authorization is making sure that someone is able to access what they are trying to access. So, a normal user for instance, won't be able to just switch PK's.
Authorization is well documented in the link I provided above. I'd start there and run through some of the sample code. Hopefully that answers your question. If not, hopefully it provides you with enough information to come back and ask a more specific question.
This is a recurring question and also implies a serious security flaw. My contribution is this:
There are 2 basic aspects to take care of.
The first is the view:
a) Take care to add a decorator to the function-based view (such as #login_required) or a mixin to the class-based function (such as LoginRequiredMixin). I find the official Django documentation quite helpful on this (https://docs.djangoproject.com/en/4.0/topics/auth/default/).
b) When, in your view, you define the data to be retrieved or inserted (GET or POST methods), the data of the user must be filtered by the ID of that user. Something like this:
def get(self, request, *args, **kwargs):
self.object = self.get_object(queryset=User.objects.filter(pk=self.request.user.id))
return super().get(request, *args, **kwargs)
The second aspect is the URL:
In the URL you should also limit the URL to the pk that was defined in the view. Something like this:
path('int:pk/blog-add/', AddBlogView.as_view(), name='blog-add'),
In my experience, this prevents that an user sees the data of another user, simply by changing a number in the URL.
Hope it helps.
In django CBV (class based views) you can prevent this by comparing the
user entered pk and the current logged in user:
Note: I tested it in django 4 and python 3.9.
from django.http import HttpResponseForbidden
class UserDetailView(LoginRequiredMixin, DetailView):
model = your_model
def dispatch(self, request, *args, **kwargs):
if kwargs.get('pk') != self.request.user.pk:
return HttpResponseForbidden(_('You do not have permission to view this page'))
return super().dispatch(request, *args, **kwargs)