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):
# …
Related
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
)
...
I'm trying to make a custom permission using this guide
views.py
class CustomModelList(generics.ListAPIView):
queryset = CustomModel.objects.all()
serializer_class = CustomModelSerializer
permission_classes = [IsAuthenticatedOrReadOnly, IsCustomOrReadOnly]
def get(self, request, format=None):
# some logic
def post(self, request, format=None):
# some logic
Just for experiment I've created this permission not to apply anyway
pesmissions.py
class IsCustomOrReadOnly(BasePermission):
def has_object_permission(self, request, view, obj):
return False
But when POST request sends to server it takes no effect -- I'm able to create new model instance.
I think that since you are using a list view, custom object level permissions are not checked automatically.
Also note that the generic views will only check the object-level permissions for views that retrieve a single model instance. If you require object-level filtering of list views, you'll need to filter the queryset separately. See the filtering documentation for more details.
You can try overriding the has_permission method instead and see if that works, or check the permissions manually.
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)
I'm trying to crate Django web project , and there are some User backend application where every URL ( view ) only for authenticated users.
I can write a condition in every view for example:
User/urls.py
urlpatterns = patterns('',
url(r'^settings/', 'User.views.user_settings'),
url(r'^profile/', 'User.views.profile'),
#Other User Admin panel Urls
)
User/views.py
def user_settings(request):
if request.user is None:
return redirect('/login')
#Some other code
def profile(request):
if request.user is None:
return redirect('/login')
#Some other code
As you can see it's not well coded but it works fine.
The only thing that I want to know , is it possible to add some condition for urls.py file all urls for not adding same code lines in every view function.
For example Symfony , Laravel and Yii frameworks have something like that what I want to do.
Is it possible do this in Django ? :)
Edited Here
With #login_required I need to add it for every view, I need something for all urls for example:
In Symfony framework I can write
{ path: ^/myPage, roles: AUTHENTICATED } and every url like this /myPage/someUrl will be asked for authentication.
I believe that Django have something like that :)
Thanks.
Well if you use a class based view, it makes easier for you to add #login_required. For example you can create a class based view here:
class BaseView(TemplateView):
#method_decorator(login_required)
def dispatch(self, request, *args, **kwargs):
return super(BaseView, self).dispatch(*args, **kwargs)
Now override it each time you want to create a new view. For example:
class SettingsView(BaseView):
def get(request):
return (...)
It will check each time at url dispatch if the user is logged in.
Also, if you use a class based view, you can override get() to check if the user is authenticated.
class BaseView(TemplateView):
template_name= None
role= None
def get(self, request, *args, **kwargs):
if request.user is not None and role is "AUTHENTICATE":
return super(BaseView, self).get(request, *args, **kwargs)
else:
raise Exception('user is not logged in')
urls.py:
url(r'^settings/', BaseView.as_view(template_name='/sometemplate', role="AUTHENTICATE")
You can use the #login_required decorator:
https://docs.djangoproject.com/en/1.5/topics/auth/default/#the-login-required-decorator
From the docs:
login_required() does the following:
If the user isn’t logged in, redirect to settings.LOGIN_URL, passing the current absolute path in the query string. Example: /accounts/login/?next=/polls/3/.
If the user is logged in, execute the view normally. The view code is free to assume the user is logged in.
from django.contrib.auth.decorators import login_required
#login_required
def my_view(request):
...
You could use this : https://docs.djangoproject.com/en/1.6/topics/auth/default/#the-login-required-decorator
from django.contrib.auth.decorators import login_required
#login_required
def my_view(request):
...
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.