What is the best way to add custom account types in Pinax? For example, I want a Free account, and a Premium Account. However, this is not supported by the Pinax models.
Does this mean I have to fork the Pinax project? There must be an easier way. Thanks
The pinax.apps.account app is meant to handle private/system type settings like Language choice, Time Zone setting, etc. for a given user.
What you are talking about would require you build an app for you project. It would likely be specific to your domain as well as the payment provider you are planning on using.
Related
I'm enhancing the website architecture for an open-source community. I want to provide some options(or features) to authenticated users only because an open-source community always contains thousands of members which leads to a chance of spamming. I'm adding OAuth using GitHub which can prevent user spamming.
All I would like to know whether should I add OAuth on an open-source community website or not? Is it a good practice? or there is some another way I should do to prevent user-spam?
I want to prevent spamming, for example, user-2 can not update the profile of user-1 (just an example don't want to achieve this task)
If you are not building an anon targeted website, then yes, user profiles are a need. If your website user flow suggests editing other user's profiles, you can allow it in django, but why? User profiles usually are only editable by owners.
Research what OAuth provider your users might prefer. django-allauth and similar apps give you a way to easily add OAuth of any of hundreds of providers, so it's only a question what your users want to use.
I have a small personal blog created for free on wordpress.com. I'd like to convert it into static blog (powered by pelican) and move it to GitHub pages.
The wordpress blog already has a name, which I'd like to save. Unfortunately, my personal account's name is completely unrelated to the name of the blog. So I cannot achieve what I want due to fixed naming scheme {username}.github.io.
I wonder: is it OK for me to create second GitHub account for the only purpose of hosting my gh-pages blog on it? Or it goes against GitHub rules?
P.S. I know that it is possible to buy and use a custom domain outside of GitHub.
I recommend migrating to GitHub and then using Netlify's free hosting plan. It's easy to host your GitHub repo. on Netlify. Once you've done that, you can change the Site Name property in the Netlify settings. Then your new URL would be https://{your-blog-name}.netlify.com assuming it wasn't taken.
As to your question, here are the relevant Terms of Service from GitHub:
Your login may only be used by one person — i.e., a single login may not be shared by multiple people. A paid organization account may create separate logins for as many users as its subscription allows.
Overall, the number of Users must not exceed the number of accounts you've ordered from us.
- https://help.github.com/articles/github-terms-of-service/#2-account-requirements
It looks like it isn't against their terms. Tons of people do it and I don't think they really care.
I recommend against making multiple GitHub accounts because it makes things confusing especially when differentiating between which account you're using to develop locally.
This question is (I think) about object/row level permissions in Django.
We are building a community and need to be able to set permissions based on actions that users take. For example, you should not be able to start a thread until you have posted so and so many answers.
Also, the users should be able to remove content that belongs to themselves. Based on the Django documentation, it seems like the standard framework does not support permissions for instances.
Should we build on the "empty" API that Django supplies, or should we use an app for this like django-guardian, django-rules, etc? Which ones would you in that case recommend?
Thank you!
you should not be able to start a thread until you have posted so and so many answers.
You don't need to use per-object permissions for that. Actually, you don't need to use permissions for that at all. Just check if user meets the requirements in your views.
Or you can use standard django permissions engine. Create permissions like "Start a Thread", then set up signals to track when users add answers. When singal is emitted check if a user has enough answers and grant him the "Start a Thread" permission.
It's up to you to decide which one works better for you.
Also, the users should be able to remove content that belongs to themselves.
This can be done with per-object permissions. But if it's the only reason to use them then I'd just add a field author to your models and use a simple item.author == request.user check to test if user can delete the item.
So, my general advice is to keep it simple. Analyze your needs. Per-object permissions is a powerful tool which may be an overkill in your situation.
I recommend you to go with Django-guardian.
Django-guardian
Great, DRY, maintained and well-tested app, that solves the issue. As of today, this is the most maintained and actively developed library for implementing per-object permissions.
We are currently using django-guardian in one of our big projects and are very pleased with stability and functionality.
Django-guardian source code is very simple and easy to understand because it is built upon the permission code in Django core.
However, there is a minor issue with Django permissions for proxy models which is not fixed in Django core thus making it really tricky to set permissions (global and per-object alike) for them. One of the ways to overcome this is to declare all permissions in a non-proxy object and query for them every time when you need to check for permission to access a proxy model.
Per-object permission library by OSU Open Source Lab
It is more of a standalone application than Django-guardian and supports older versions of Django. This app is relatively well maintained. (I personally haven't used it.)
Other solutions form older posts.
But most of them are poorly maintained.
Of course, if you need to implement only a few minor checks, row-level permissions are overkill, just like Andrey said.
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.
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.