I want to control that only the superuser and for example the teacher, can access a page inherited from UpdateView and redirect others to the /404 page.
My class in views.py :
class Edit_news(UpdateView):
model = News
form_class = edit_NewsForm
template_name = "profile/Edit_news.html"
URL of class in urls.py :
from django.urls import path
from .views import Edit_news
urlpatterns = [
path("edit-news/<pk>", Edit_news.as_view()),
]
Solution 1
You can override View.dispatch() which is the entrypoint of any HTTP methods to check first the user.
dispatch(request, *args, **kwargs)
The view part of the view – the method that accepts a request argument plus arguments, and returns a HTTP response.
The default implementation will inspect the HTTP method and attempt to delegate to a method that matches the HTTP method; a GET
will be delegated to get(), a POST to post(), and so on.
class Edit_news(UpdateView):
...
def dispatch(self, request, *args, **kwargs):
if (
request.user.is_superuser
or request.user.has_perm('app.change_news') # If ever you attach permissions to your users
or request.user.email.endswith('#teachers.edu.org') # If the email of teachers are identified by that suffix
or custom_check_user(request.user) # If you have a custom checker
):
return super().dispatch(request, *args, **kwargs)
return HttpResponseForbidden()
...
If you want it to be different for HTTP GET and HTTP POST and others, then override instead the specific method.
class django.views.generic.edit.BaseUpdateView
Methods
get(request, *args, **kwargs)
post(request, *args, **kwargs)
Related reference:
Add object level permission to generic view
Solution 2
You can also try UserPassesTestMixin (the class-based implementation of user_passes_test).
class Edit_news(UserPassesTestMixin, UpdateView): # Some mixins in django-auth is required to be in the leftmost position (though for this mixin, it isn't explicitly stated so probably it is fine if not).
raise_exception = True # To not redirect to the login url and just return 403. For the other settings, see https://docs.djangoproject.com/en/3.2/topics/auth/default/#django.contrib.auth.mixins.AccessMixin
def test_func(self):
return (
self.request.user.is_superuser
or self.request.user.has_perm('app.change_news') # If ever you attach permissions to your users
or self.request.user.email.endswith('#teachers.edu.org') # If the email of teachers are identified by that suffix
or custom_check_user(self.request.user) # If you have a custom checker
)
...
Related
I want to know the major difference between self.request.user (when using generic view View) and request.user (when using a user defined view), at times when I use django's generic View (django.views.generic import View) which has access to the django User model, I'd interact with the authenticated user as request.user and self.request.user without having any problem.
For instance, in a django views.py:
from django.contrib.auth import get_user_model
User = get_user_model()
class GetUserView(View):
def get (self, request, *args, **kwargs):
user_qs = User.objects.filter(username=request.user.username)
#Do some other stuffs here
class AnotherGetUserView(View):
def get(self, request, *args, **kwargs):
user_qs = User.objects.filter(username=self.request.user.username)
#Do some other stuffs here
I realize that the two queryset works fine but I can't still figure out the best to use.
There is no difference. Before triggering the get method, it will run the .setup(…) method [Django-doc] which will set self.request = request as well as self.args and self.kwargs to the positional and named URL parameters respectively. Unless you override this, self.request will thus always refer to the same object as request, and the documentation explicitly says that you should not override the .setup(…) method without making a call to the super method which will thus set self.request.
It however does not make much sense to do User.objects.filter(username=request.user.username): you already have the user object: that is request.user, so here you will only make extra database requests. user_qs is simply a queryset with one element: request.user. You can thus for example use request.user.email to obtain the email address of the logged in user.
You might want to use the LoginRequiredMixin [Django-doc] to ensure that the view can only be called if the user has been logged in, so:
from django.contrib.auth.mixins import LoginRequiredMixin
class GetUserView(LoginRequiredMixin, View):
def get (self, request, *args, **kwargs):
# …
I'm using a Django package named django-safedelete that allows to delete users without removing them from the database.
Basically, it adds a delete attribute to the model, and the queries like User.objects.all() won't return the deleted models.
You can still query all objects using a special manager. For example User.objects.all_with_deleted() will return all users , including the deleted ones. User.objects.deleted_only() will return the deleted ones.
This works as expected, except in one case.
I'm using Token Authentication for my users with Django Rest Framework 3.9, and in my DRF views, I'm using the built-in permission IsAuthenticated.
Code of a basic CBV I'm using:
class MyView(APIView):
permission_classes = (IsAuthenticated,)
def get(self, request):
return Response(status=HTTP_200_OK)
Code of the DRF implementation of IsAuthenticated permission:
class IsAuthenticated(BasePermission):
"""
Allows access only to authenticated users.
"""
def has_permission(self, request, view):
return bool(request.user and request.user.is_authenticated)
The problem
When a user is soft deleted, he's still able to authenticate using its token.
I'm expecting the user to have a 401 Unauthorized error when he's soft deleted.
What's wrong?
The DRF already uses the is_active property to decide if the user is able to authenticate. Whenever you delete a user, just be sure to set is_active to False at the same time.
For django-safedelete:
Since you're using django-safedelete, you'll have to override the delete() method to de-activate and then use super() to do the original behavior, something like:
class MyUserModel(SafeDeleteModel):
_safedelete_policy = SOFT_DELETE
my_field = models.TextField()
def delete(self, *args, **kwargs):
self.is_active = False
super().delete(*args, **kwargs)
def undelete(self, *args, **kwargs):
self.is_active = True
super().undelete(*args, **kwargs)
Note that this works with QuerySets too because the manager for SafeDeleteModel overrides the QuerySet delete() method. (See: https://github.com/makinacorpus/django-safedelete/blob/master/safedelete/queryset.py)
The benefit to this solution is that you do not have to change the auth class on every APIView, and any apps that rely on the is_active property of the User model will behave sanely. Plus, if you don't do this then you'll have deleted objects that are also active, so that doesn't make much sense.
Why?
If we look into the authenticate_credentials() method of DRF TokenAuthentication [source-code], we could see that,
def authenticate_credentials(self, key):
model = self.get_model()
try:
token = model.objects.select_related('user').get(key=key)
except model.DoesNotExist:
raise exceptions.AuthenticationFailed(_('Invalid token.'))
if not token.user.is_active:
raise exceptions.AuthenticationFailed(_('User inactive or deleted.'))
return (token.user, token)
Which indicates that it's not filtering out the soft deleted User instances
Solution?
Create a Custom Authentication class and wire-up in the corresponding view
# authentication.py
from rest_framework.authentication import TokenAuthentication, exceptions, _
class CustomTokenAuthentication(TokenAuthentication):
def authenticate_credentials(self, key):
model = self.get_model()
try:
token = model.objects.select_related('user').get(key=key)
except model.DoesNotExist:
raise exceptions.AuthenticationFailed(_('Invalid token.'))
if not token.user.is_active or not token.user.deleted: # Here I added something new !!
raise exceptions.AuthenticationFailed(_('User inactive or deleted.'))
return (token.user, token)
and wire-up in views
# views.py
from rest_framework.views import APIView
class MyView(APIView):
authentication_classes = (CustomTokenAuthentication,)
permission_classes = (IsAuthenticated,)
def get(self, request):
return Response(status=HTTP_200_OK)
How can I make a ModelViewSet accept the POST method to create an object? When I attempt to call the endpoint I get a 405 'Method "POST" not allowed.'.
Within views.py:
class AccountViewSet(viewsets.ModelViewSet):
"""An Account ModelViewSet."""
model = Account
serializer_class = AccountSerializer
queryset = Account.objects.all().order_by('name')
Within serializers.py:
class AccountSerializer(serializers.ModelSerializer):
name = serializers.CharField(required=False)
active_until = serializers.DateTimeField()
class Meta:
model = Account
fields = [
'name',
'active_until',
]
def create(self, validated_data):
with transaction.atomic():
Account.objects.create(**validated_data)
within urls.py:
from rest_framework import routers
router = routers.SimpleRouter()
router.register(
prefix=r'v1/auth/accounts',
viewset=AccountViewSet,
base_name='accounts',
)
Do I need to create a specific #action? my attempts to do so have yet to be successful. If that is the case what would the url = reverse('app:accounts-<NAME>') be such that I can call it from tests? I haven't found a full example (urls.py, views.py, serializers.py, and tests etc).
I discovered what the issue was, I had a conflicting route. There was a higher level endpoint registered before the AccountViewSet.
router.register(
prefix=r'v1/auth',
viewset=UserViewSet,
base_name='users',
)
router.register(
prefix=r'v1/auth/accounts',
viewset=AccountViewSet,
base_name='accounts',
)
Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL.. I should have been ordered this way:
router.register(
prefix=r'v1/auth/accounts',
viewset=AccountViewSet,
base_name='accounts',
)
router.register(
prefix=r'v1/auth',
viewset=UserViewSet,
base_name='users',
)
despite the fact that reverse('appname:acccounts-list') worked, the underlying URL router still thought I was calling the UserViewSet.
From the docs:
A ViewSet class is simply a type of class-based View, that does not provide any method handlers such as .get() or .post(), and instead provides actions such as .list() and .create().
And here is a list of supported actions:
def list(self, request):
pass
def create(self, request):
pass
def retrieve(self, request, pk=None):
pass
def update(self, request, pk=None):
pass
def partial_update(self, request, pk=None):
pass
def destroy(self, request, pk=None):
pass
So no post is not directly supported but create is.
So your end point would be v1/auth/accounts/create when using the a router instead v1/auth/accounts/post.
I honestly prefer using class based or function based views when working with DRF. It resembles regular django views more closely and makes more sense to me when working with them. You woul write you views and urls pretty much like regular django urls and views.
I want to create DRY Django Mixins for things I do frequently. I have multiple Access Mixins that all need current Organization, so I wanted the code responsible for getting the Organization to be in separate Mixin, that also inherits from Djangos LoginRequiredMixin, because we will always check that if we're in organization page.
But instead of preforming dispatch method of inherited classes, saving the response and doing its thing, it skips it.
I started reading about Python's MRO and all, but I still can't find a way to make it all work.
Is my basic idea wrong? What is the best way to achieve this?
Thanks in advance,
Paweł
Code:
class OrganizationMixin(LoginRequiredMixin):
"""
CBV mixin for getting current organization.
Inherits from `LoginRequiredMixin` because we need logged in user to check
their membership and/or organization role.
"""
org_kwarg_name = 'organization_slug'
organization = None
def dispatch(self, request, *args, **kwargs):
response = super().dispatch(request, *args, **kwargs)
self.organization = self.get_organization()
return response
def get_organization(self):
# Get the slug from URL
slug = self.kwargs.get(self.org_kwarg_name, None)
return get_object_or_404(Organization, slug=slug)
class MembershipRequiredMixin(OrganizationMixin, AccessMixin):
"""
CBV mixin for checking if user belongs to current organization.
Already checks if user is logged in.
"""
permission_denied_message = _("You need to belong to the organization "
"to visit this page.")
def dispatch(self, request, *args, **kwargs):
response = super().dispatch(request, *args, **kwargs)
# Check if user is a member or a superuser
if (not self.organization.is_member(request.user) and
not request.user.is_superuser):
return self.handle_no_permission()
return response
I believe this is a simple one, just can't spot the solution. I have a view that does a bit of work on the server then passes the user back to another view, typically the original calling view.
The way I'm rendering it now, the url isn't redirected, ie it's the url of the original receiving view. So in the case the user refreshes, they'll run that server code again.
class CountSomethingView(LoginRequiredMixin, View):
def get(self, request, *args, **kwargs):
# so some counting
view = MyDetailView.as_view()
return view(request, *args, **kwargs)
I strongly recommend not overriding get or post methods. Instead, override dispatch. So, to expand on Platinum Azure's answer:
class CountSomethingView(LoginRequiredMixin, RedirectView):
permanent = False
def get_redirect_url(self, **kwargs):
url = you_can_define_the_url_however_you_want(**kwargs)
return url
def dispatch(self, request, *args, **kwargs):
# do something
return super(CountSomethingView, self).dispatch(request, *args, **kwargs)
when a user does an action and I need to redirect him to the same page, first of all I use a templateView to display a simple "thanks" (for example) then provide a link to go back to the previous page with a simple {% url %}
for example :
from django.views.generic import CreateView, TemplateView
from django.http import HttpResponseRedirect
class UserServiceCreateView(CreateView):
form_class = UserServiceForm
template_name = "services/add_service.html"
def form_valid(self, form):
[...]
return HttpResponseRedirect('/service/add/thanks/')
class UserServiceAddedTemplateView(TemplateView):
template_name = "services/thanks_service.html"
def get_context_data(self, **kw):
context = super(UserServiceAddedTemplateView, self).\
get_context_data(**kw)
context['sentance'] = 'Your service has been successfully created'
return context
in the template thanks_service.html i use {% url %} to go back to the expected page
Hope this can help
Performing a redirect in a Django Class Based View is easy.
Simply do a return redirect('your url goes here').
However, I believe this isn't what you want to do.
I see you're using get().
Normally, when speaking about HTTP, a GET request is seldom followed by a redirect.
A POST request is usually followed by a redirect because when the user goes backwards you wouldn't want to submit the same data again.
So what do you want to do?
What I think you want to do is this:
def get(self, request, *args, **kwargs):
return render_to_response('your template', data)
or even better
def get(self, request, *args, **kwargs):
return render(request, self.template_name, data)
If you're creating or updating a model, consider inheriting from CreateView or UpdateView and specifying a success_url.
If you're really doing a redirect off of an HTTP GET action, you can inherit from RedirectView and override the get method (optionally also specifying permanent = False):
class CountSomethingView(LoginRequiredMixin, RedirectView):
permanent = False
def get(self, request, *args, **kwargs):
# do something
return super(CountSomethingView, self).get(self, request, *args, **kwargs)
Note that it's really bad practice to have a get action with side-effects (unless it's just populating a cache or modifying non-essential data). In most cases, you should consider using a form-based or model-form-based view, such as CreateView or UpdateView as suggested above.