I'm using dry-rest-permission package to write authentication for django webService. When I write permission method as same as the package docs I encounter internal server error and this :'bool' object is not callable
And this is my method:
#staticmethod
#authenticated_users
def has_create_permission(request):
return True
I guess you're using incompatible version of dry-rest-permission with your current django framework. In #authenticated_users decorator request.user.is_authenticated() is called but in newer version of django is_authenticated has changed to a bool attribute from a function returning bool.
You could refer to their last commits that correct usage of is_authenticated.
As it seems they doesn't release that commit yet you have to apply referred path manually to get rid of the error.
Per that page: "Using User.is_authenticated() and User.is_anonymous() as methods rather than properties is no longer supported."
Hope this can help you:
https://github.com/chibisov/drf-extensions/issues/200
Related
Is there any possibility to cancel permissions for some part of function, wich specified to function with #is_stuff decorator in Django (1.4.11) with python 2.7?
I mean the following:
#is_stuff(required_perms='<permissions>')
def my_function(request):
if request.POST['key']:
# do something as admin (1)
else:
# there I want to cancel permissions limitation (2)
I know that this is unusual using of decorators. And that decorators called before performing of function. But I am still interested is it possible? Maybe I can make something like this - dynamically change user.is_staff to True as in second link?
Related links where I didn't find answers:
Official docs, official docs (2nd link)
I want to modify the default Django error reporting template TECHNICAL_500_TEXT_TEMPLATE to provide custom error message. Read doc on modifying the filter tried
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter' but it's about filtering data but I would like to override the default template itself.
Tried overriding DEFAULT_EXCEPTION_REPORTER_FILTER and defining custom get_traceback_text and hence passing custom template instead of TECHNICAL_500_TEXT_TEMPLATE in the method.
Any suggestions would be helpful
I started noticing the change in the emails after upgrading from 1.7 to 1.9. I used the approach in the following answer. I basically removed the 'settings' section from the templates, including a few other lines that weren't needed.
Django error email is too long. How do I truncate it?
I have been using
the braces LoginRequired Mixin in the past, Now it does not seem to work. No errors just you can see the view without Logging in.
Is this the same library?
It seems that a lot of things have changed in django since the last time I have used it. thanks.
You can use official django login_required method.
from django.contrib.auth.decorators import login_required
class SomeClassView(View):
#classmethod
def as_view(cls, **initkwargs):
view = super(SomeClassView, cls).as_view(**initkwargs)
return login_required(view)
Documentation: https://docs.djangoproject.com/en/1.8/topics/auth/default/#the-login-required-decorator
Yes, this is the same library. The ReadTheDocs link that you posted links directly to the brack3t/django-braces page linked in your question.
Regarding versioning, here is the statement from the Readme.md file:
Our policy going forward is that django-braces officially supports the current version of Django and one version each direction (e.g. 1.6.x is current, so 1.5.x, 1.6.x, and 1.7.x are all supported). There won't be any restraints on using other versions of Django, though, but it will be a "buyer beware" situation.
According to the repo's releases page, v1.8 is current, so it should support Django 1.7.x, 1.8.x, and 1.9.x under the current release.
I've just plugged this old JSONField model snippet into my django application. It looks like it's working, but throws this warning whenever the server revalidates:
$ sudo python manage.py runserver
Validating models...
/opt/bitnami/apps/django/lib/python2.6/site-packages/django/db/models/fields/subclassing.py:80:
DeprecationWarning: A Field class whose get_db_prep_save method hasn't been updated to take a `connection` argument.
new_class = super(SubfieldBase, cls).__new__(cls, name, bases, attrs)
0 errors found
What does this mean? How do I fix it?
It's a warning telling you that the the custom JSON field implemented in that snippet hasn't included the connection argument that has been introduced in django 1.2 due to multiple database support being implemented.
With regards the method itself: If you are writing a custom model field, you can use the get_db_prep_save to convert the python object you are working with (in this case a JSON object) into a form that the database backend can manage (in this case a string) before it is saved to the DB. Here are the release notes mentioning it
With regard the connection argument, it refers to the current database (at the time of execution - to get the default you can call django.db.connection) and it is included to ensure that the correct database is provided when calling that method so that any custom backend logic or convertions can be carried out before the value is saved to the db. You can read more about connections and cursors here
You can also use http://pypi.python.org/pypi/django-jsonfield, it is basically a packaging-up of the code snippet you mention.
(I had an older version that gave me the same connection error you mentioned; the newer versions have fixed this).
You can also try this one: https://github.com/vialink/vlk-django-jsonfield
We are using it in some projects and it is working fine.
There are apparently two different ways to return a 404 error in Django: by returning a HttpResponseNotFound object or by raising an Http404 exception. While I'm using the former in my project, it seems that Django's internal views are mostly using the latter. Apart from the "Exception is exceptional" mantra, what's the difference between both ways and which should I be using?
An HttpResponseNotFound is just like a normal HttpResponse except it sends error code 404. So it's up to you to render an appropriate 404 page in that view, otherwise the browser will display its own default.
Raising an Http404 exception will trigger Django to call its own 404 error view. Actually, this does little more than render the 404.html template and send it - using HttpResponseNotFound, in fact. But the convenience is that you're then specifying the template (and view, if you like) in one place.
In addition to what Daniel said, raising an Http404 exception can be more flexible in that it allows you to generate a 404 e.g. from a helper function deeper in your call stack (possibly one that usually returns a non-HttpResponse type) and rely on Python's exception propagation instead of having to create a HttpResponseNotFound and manually pass it back up to where you were originally crafting your response.
In addtion to what Daniel and esmail said, for reference, this is literally the definition of HttpResponseNotFound Django (v1.8):
class HttpResponseNotFound(HttpResponse):
status_code = 404
And for good measure, the definition of Http404:
class Http404(Exception):
pass