The main permission checking methods in Django REST Framework, BasePermission's has_permission and has_permission, both return True, effectively making any permission checking allow by default. Since this is counter to a security mindset and OWASP recommendations I would like to fix the implementation locally before reporting a bug. I could fix it for my own classes by subclassing BasePermission but I want to ensure that every subclass of BasePermission used anywhere does deny by default. Can I replace the functionality of these two methods for every subclass in my Django system without actually patching the BasePermission implementation?
To be clear, I am not trying to do this for testing purposes.
Related
I have a pyramid API which has basically three layers.
View -> validates the request and response
Controller -> Does business logic and retrieves things from the DB.
Services -> Makes calls to external third party services.
The services are a class for each external API which will have things like authentication data. This should be a class attribute as it does not change per instance. However, I cannot work out how to make it a class attribute.
Instead I extract the settings in the view request.registry.settings pass it to the controller which then passes it down in the init() for the service. This seems unnecessary.
Obviously I could hard code them in code but that's an awful idea.
Is there a better way?
Pyramid itself does not use global variables, which is what you are asking for when you ask for settings to be available in class-level or module-level attributes. For instance-level stuff, you can just pass the settings from Pyramid into the instance either from the view or from the config.
To get around this, you can always pass data into your models at config-time for your Pyramid app. For example, in your main just pull settings = config.get_settings() and pass some of them to where they need to be. As a general rule, you want to try to pass things around at config-time once, instead of from the view layer all the time.
Finally, a good way to do that without using class-level or module-level attributes is to register instances of your services with your app. pyramid_services library provides one approach to this, but the idea is basically to instantiate an instance of a service for your app, add it to your pyramid registry config.registry.foo = ... and when you do that you can pass in the settings. Later in your view code you can grab the service from there using request.registry.foo and it's already setup for you!
I am new to Django and Django-Rest. I am confused about when I should use these? what are their advantages and disadvantages? I have only seen this- http://www.cdrf.co
The only thing I know is there are a lot of ways to do 1 thing. But this is totally unclear to me.
In Django, these four terms we use frequently for different purposes in the projects. I have tried to collect and share the actual meaning with the links to details description of each term. Please check if you find these helpful.
Generic views:
“Django’s generic views... were developed as a shortcut for common usage patterns... They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself.”
— Django Documentation
Read more details
Views:
A view function, or view for short, is simply a Python function that takes a Web request and returns a Web response. This response can be the HTML contents of a Web page, or a redirect, or a 404 error, or an XML document, or an image . . . or anything, really. The view itself contains whatever arbitrary logic is necessary to return that response. This code can live anywhere you want, as long as it’s on your Python path. There’s no other requirement–no “magic,” so to speak. For the sake of putting the code somewhere, the convention is to put views in a file called views.py, placed in your project or application directory.
Read more details
Viewsets:
Django REST framework allows you to combine the logic for a set of related views in a single class, called a ViewSet. In other frameworks, you may also find conceptually similar implementations named something like 'Resources' or 'Controllers'.
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().
The method handlers for a ViewSet are only bound to the corresponding actions at the point of finalizing the view, using the .as_view() method.
Read more details
Mixins:
The mixin classes provide the actions that are used to provide the basic view behavior. Note that the mixin classes provide action methods rather than defining the handler methods, such as .get() and .post(), directly. This allows for more flexible composition of behavior.
The mixin classes can be imported from rest_framework.mixins.
Read more details
This is more of a conceptual question. While learning the Django class-based view, I am wondering if it is possible to make a call to a Django view as an initiation call. I mean, after the first call, the following calls from the templates can share the instance variables created by the first one. This avoids passing variables back and forth between the template and server.
No. Django views are specifically designed to prevent this. It would be a very bad idea; any instance variables set would be shared by all future users of that process, leading to potential information leakage and other thread-safety bugs.
If you want to store information between requests, use the session.
I am configuring access control for a web application based on the Pyramid framework. I am setting up permissions for my view callables using the #view_config decorator. I have two permissions, namely 'read' and 'write'. Now, I want certain views to require both permissions. I was unable to figure out how to do this with view_config - am I missing something, or is there maybe another way to do this?
Make a readwrite permission. Each view gets one and only one permission but each principal can be mapped to many permissions.
I am a beginner in Web2Py. I wish to develop a simple application, where the user should log in with a username and a password (no fancy stuff like login with facebook or OpenID etc.). Upon successful login, the user sees some interface, and performs certain operations. I imagined a User class and a JobStore class (which has certain methods defined, which the user should be able to call). There will be only one JobStore object for all users and sessions. When a user logs in, an User object gets created with a reference to the JobStore. The User class has methods like GetRights(), RequestJob(), MarkAsFinished(), etc. and JobStore has methods like GetUnfinished(), RemoveJobs(), etc. Structurally speaking, where am I supposed to have these classes, so that based on certain actions the user performs on the view, certain methods get called? Are these classes supposed to inherit from some standard classes used in Web2Py? I am trying to find an example, where some kind of object oriented approach is used in the controller, but have not found any so far. Also, is this the wrong approach in Web2Py app development? I am not trying to implement any complex business logic through these functions as of now; I am just trying to understand how traditional programming approach would map to Web2Py approach somehow.
You can define classes in model or controller files, but it would probably make most sense to put them in the app's /modules folder and import them where needed in your models and controllers. There is no need for your classes to inherit from web2py classes, though they can do so if desired. For more on using modules and importing, see here and here.
For an example of a heavily object-oriented approach, see the Movuca CMS. Most of the code is in the /modules folder.