I'm building a Django-based review website where public users create all of the content on the site. Users create reviews for given items and they also create the items themselves that will be reviewed (providing a description and brief summary of the item, along with a few tags).
My question is this: Should I be using Django's admin features for this website (as in, exposing admin controls to the public users)? Or should I just stick with normal forms? I'm not too familiar with the admin-aspect of Django, and so far I've just been using forms for the website, but I've seen a lot of people talking about Django's admin features, and I'm starting to wonder if I should be using them.
Thanks for any feedback!
Maybe. If the admin functionality covers most of what you want to offer, there's no reason why you shouldn't use it as a starting point.
django.contrib.admin is an application like any other, and provides basically a CRUD interface to your models. Access can be controlled via groups/permissions, just like you would for an application you write yourself. You can give full access to a model with a one-liner, but obviously will have to configure properly when opening up to others.
See also my question
Django AdminSite/ModelAdmin for end users?
and similar questions Exposing django admin to users. Harmful? and How to make Django admin site accessed by non-staff user?
Regarding arguments about the "intended use" of the admin, please note Django's security update at the end of last year: http://www.djangoproject.com/weblog/2010/dec/22/security/ regarding querystring parameters in object lists. Such an update (quote: "an attacker with access to the admin [...]") is a clear indication that the admin's implementation of the permission system is being constantly scrutinized.
No. The django admin is not intended for any end-user.
The django admin feature is intended to assist the website developer, and that is all. Even usage by site administrators is contra-indicated, although in practice most small sites get away with it since they're only talking a few people who can call on the developer personally if they get into trouble.
For your purposes, the review items and the workflow in creating the items is a critical part of your application feature set. The admin will give you ideas, but it would be a mistake to attempt to build your application upon it.
I wouldn't expose the admin interface to regular users. You can use the authentication and user-management side (for your purposes), but it's usually best practice to give users a separate way to manage their objects. You also don't run as much of a risk of granting the wrong privileges to users (or allowing them to grant their own).
Have a read though the docs if you want a better overview about what it can do.
Related
I understand that Django is an ORM that you can use to build APIs and external UIs for; dashboard allows ACL access and various data-management functionality.
Is generally okay or not a good idea to allow public users to use portions of the dashboards, i.e. forms?
It is not usual, but it depends on your project and the audience of your project. I will leave you here a resume about Django book said about it, and you must decide it is suitable for your project and uses cases.
According to the django book:
Django’s admin site uses a permissions system that you can use to give specific users access only to the portions of the interface that they need. These user accounts are meant to be generic enough to be used outside of the admin interface, but we’ll just treat them as admin user accounts for now. In Chapter 11, we’ll cover how to manage users site-wide (i.e. not just the admin site) with Django’s authentication system.
And on the same page ...
When and Why to Use the Admin Interface – And When Not to
Django’s admin site shines when nontechnical users need to be able to enter data; that’s the purpose behind the feature, after all. At the newspaper where Django was first developed, development of a typical online feature – say, a special report on water quality in the municipal supply – would go something like this:
The reporter responsible for the project meets with one of the developers and describes the available data.
The developer designs Django models to fit this data and then opens up the admin site to the reporter.
The reporter inspects the admin site to point out any missing or extraneous fields – better now than later.
In other words, the raison d’etre of Django’s admin interface is facilitating the simultaneous work of content producers and programmers. However, beyond these obvious data entry tasks, the admin site is useful in a few other cases:
Inspecting data models.
Managing acquired data.
Quick and dirty data-management apps.
For a website that is using django zinnia blog, I need the possibility to, beyond authors using the admin to create articles, to have a limited way for non-admin users to create blog entries, in their own specific area, with limited functionality (e.g. preset category, all entries start as draft etc..)
Now I was wondering if I could just create an own small ui for it and create Entries programatically in a django view (not in admin)... (with authors in those cases being non-admin users) ...
Is there any reason why this would be a very bad idea, or is this something that would really break things in Zinnia ?
Thanks in advance
Cheers
Thomas
I've done one part of this a few months ago. The client found the admin interface too complicated and wanted something simpler. I created view/templates that allowed users to add/edit blog entries - There were no major issues.
That said, this was still for admin users - there may be permission issues or hidden assumptions in zinnia that users are admins. I doubt there would be much trouble overcoming them - it's a nicely written app with decent interfaces.
I can show you some code if you're interested.
I am working on a Django somewhat e-commerce project, where, briefly, I have both a Customer and a Merchant model. The Merchant model is associated with a MerchantStore model which is somehow "complicated", having a plethora of m2m and foreign key relationships to various models.
Following the solution in this post and having not enough "time" to make a custom implementation, I decided to let each Merchant be a "stuff member" and customize his store through the admin interface. Of cource I created a new group with the appropriate permissions.
However, some questions arise:
1) Is this considered harmful? Are there any security threats associated?
2) Isn't this the best way to do it if you have not enough time anyway?
No, I would not consider this harmful.
The "Zen of Admin" as described in Apress's djangobook seemed to imply an assumption of trust as part of the admin's "philosophy", and paired with the often-repeated "admin is not your app" advice, I too was scared at first and think the Django documentation could point out intended, viable use cases.
Please see my almost identical question Django AdminSite/ModelAdmin for end users?
From Jordan's answer (who I gave the bounty):
There is nothing inherently special
about admin. It behaves just like any
other view. So if it is using
permissions to determine access (for
example, if you set a user's .is_staff
to True but give them access only to
specific permissions) then it will be
equally secure to any view you might
create that uses permissions to
determine access.
...
The people who wrote
django.contrib.admin did not write it
with the assumption that anyone with
an is_staff = True could be trusted as
much as a superuser, or was stupid
enough to never take a look at the
source code of a web page. Although
writing your own views is encouraged,
it is still a robust interface.
Also note Django's relatively recent security update http://www.djangoproject.com/weblog/2010/dec/22/security/
regarding querystring parameters in object lists.
Such an update (quote: "an attacker with access to the admin [...]") is a clear indication that the admin's implementation of the permission system is being constantly scrutinized.
Yes, this is considered "harmful", mostly due to the design considerations of the Django developers. The admin revolves around a concept of "trusted users". In other words, if someone is a staff member (thereby having access to the admin), they presumably have enough of your trust to not be worried about security breaches. Now in truth, you could block them from portions they're not supposed to mess with (as you've done), but the point is that Django makes no guarantees in this area. You probably won't have any problems, in all actuality, but you could.
Ironically, I think I've spent more time in my life customizing the Django admin than it would have taken me to build it from scratch. Funny how that goes. Regardless, I'd liken it to using scaffolding in Ruby on Rails. It's a quick way to get something live, but the goal is to replace it as soon as possible.
I have recently being trying to create a project which has several levels of user involved.
(Just an example of an abbreviated and rough schema)
ME (Super User)
Client(s)
Customer(s)
Survey Collections
SurveyUser(s)
Invitee(s)
Surveys
Invitee(s) (invitee is a child of both survey and user)
Questions
Etc
I would ideally have:
www.example.com/client/ go to a client interface which you had to be a client to access
www.example.com/customer/ go to a customer interface which you had to be a customer to access
I have already established that using a customised Django admin interface for all of them is probably not going to be possible (or is it?). I am therefore leaning towards manually creating 'admin' interfaces for each level of user, allowing them to manage their respective roles. What is the best way of having different user types and separate interfaces for each one?
I like the way of inheriting users outlined at:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/
But am unsure how I would set up different 'admin' areas for different users.
As a side issue that is related, I am also unsure of how to access the custom properties alongside standard user properties and how to edit/save them in the ACTUAL admin interface that I will use.
I would need to authenticate 'Client' users against a client database to check they are clients but somehow also authenticate against the user database which manages authentication, username, password etc.
I am switching from PHP to Python/Django so any advice greatly appreciated to help me along.
Thanks!
The closest I got to this was based on another stackoverflow article here: How to have 2 different admin sites in a Django project?
I ended up creating two entirely separate instances of django.contrib.admin.sites.AdminSite which seemed to work in the end, albeit not ideal.
Just fishing for ideas here.
Do any of the major template presentation frameworks (such as Smarty, Django) have prebuilt login/security handling? I want to save time on the security handling because it will consume a lot of time to worry about that. I want to build a site from ground up but I dont really want to go so far as starting with a completed content management system like Joomla or Drupal... thats way overkill. I prefer Java, C#, or PHP and I want to start from as close to "scratch" as I can.
Yes, Django has a complete authentication/authorization framework - see the docs here.
For registration, James Bennett's add-on project django-registration is excellent and popular.
Edited after comment: Django itself supplies the mechanism for allowing admins to create user credentials, storing them in the db, validating them on login, and restricting access to areas of the site based on privileges.
django-registration provides the mechanism for a user to sign up for a username via the site, via an email with a one-time confirmation URL which sets the login up as valid. There are various other plug-in projects which provide variations on this userflow, which may be useful depending how you want your site to work.