Hey i have one question about creating superuser with djangorestframework.
I want to create superuser with POST request using DRF 3.14
How should i do that if i'm using Android as a client for example?
Assuming you know what you are doing (superusers are quite powerful in Django), I suggest you include the following snippet in your DRF view:
from django.core import management
management.call_command('createsuperuser', **yourargs)
Full documentation can be found in the Django docs
https://django-rest-auth.readthedocs.io/en/latest/installation.html here is the official docs about social login in django-rest-auth. they say the way to make the LoginView(GithubLogin, FacebookLogin, etc..) inheriting SocialLoginView like this.
from allauth.socialaccount.providers.github.views import GitHubOAuth2Adapter
from allauth.socialaccount.providers.oauth2.client import OAuth2Client
from rest_auth.registration.views import SocialLoginView
class GithubLogin(SocialLoginView):
adapter_class = GitHubOAuth2Adapter
callback_url = CALLBACK_URL_YOU_SET_ON_GITHUB
client_class = OAuth2Client
but when i try to access the url with this as as.view(), they always say
{
"non_field_errors": [
"View is not defined, pass it as a context variable"
]
}
I tried the best. I have been suffering it for a few days. plz anybody save my life..
What's wrong with it? I've searched a lots but there wasn't any good answer for me.
So I've done a little digging and I discovered the problem.
The django-rest-auth package is no longer maintained and thus does not support modern versions of django rest framework. At the time of this post, up to version 3.10.3 of DRF is verified to work and I can verify that version 3.12.1 (and presumably onward) does not.
It looks like the project has been forked to dj-rest-auth and is receiving further support there. I would recommend migrating to that package.
You can read more about the decision to stop maintenance and fork to a new repository here.
How should I integrate Django-REST-API framework in an existing application or I have to create a new project?
You do not need to begin a new project. The basic steps are:
Install DRF, something like pip install djangorestframework
Add rest_framework to your INSTALLED_APPS
Define your serialisers, views and routes.
And that's it.
I suggest you follow the Quickstart and step through the Tutorial — it's pretty welcoming really.
I hope that helps.
I created a short note about how to do this with the photo gallery app tutorial from the Forcier et. al. book. I'm a Django noob, so please take this stuff as not-authoritative-perhaps-not-even-good. Here's the link to the post:
https://technote.fyi/blog/2018/01/26/how-to-add-rest-api-existing-django-project/
Basically, you create a new app, then in it write code for only three files: serializers.py, views.py, and urls.py. You don't write anything in models.py. Instead, you import the models from the existing app.
You then start off by creating serializers for all the models you want to expose, and then views for those serializers, and, finally, urls to call those views.
a newbie django question
I want to use 3rd party app, but I need to make some mods to it (in this case, the app is django-registration, and I need to change things such as allowing registration without confirmation email)
Initially, I simply installed the app in the general site-packages folder, and changed the code there. Now that I put my code on bitbucket I need a way to be able to keep my mods in the repository in a usable way, and uploading the full python code doesn't sound like a good idea.
I guess the best way would be to keep the 3rd party app in site-packages, and create an app in my project to keep my changes. In my case, I'd create my-django-registration in my project, and then import this when I need it in my code, rather than django-registration.
I also read about virtualenv, but I think that's mostly used for being able to use multiple environments in the same machine (in fact, somewhere it advises against changing the modules installed in the virtualenv), and doesn't help me with keeping my changes in a repository.
Any comments welcome!
Thanks
In general, you should reuse and override the behavior in 3rd party apps and not modify their sources.
What you'll most often encounter is that apps ship models that may not necessarily cover your needs, but do most of the work; you'll have forms that are almost perfect, but need that little something; you'll have views that would be perfect if you can just change one thing; you'll have URLs that are sane, but you need something more from them.
In most cases, that would just require that you create a custom app and rewire everything. Ship your own URLs that map to views that you've extended and overrode methods for custom behavior; supply it with a model form who's Meta is using the new model that you've extended from the original; so forth...
That's just the tip of the iceberg of what you can do, there's more ways when your creative. I can give you an example of how I've used the RegistrationProfile model, but shipped my own URL patterns and a custom class-based view that handled the registration process.
Now, where virtualenv comes into play is that you'll most likely be using pip to specify and supply your required dependencies in the requirements file format. That's when you want to say: "I've extended the django-registration app, but it won't work cleanly with just any version. It has to be of release X", or , "a checkout from the repository of commit Y".
This blog post that adresses this issue is extremely helpful. For convenience I copy-paste it here:
You don’t touch external app code
You are not supposed to edit the code from an external app. Unless you fork it first on github.
So, how to override without forking:
Overriding a template
If you want to override templates/userena/activate_fail.html, then all you have to do is create your own templates/userena directory and make your own activate_fail.html in it.
Overriding a url
Probably the first thing you should check in an external app is its urls.py. Views that are properly coded should support plenty of arguments. For example, userena has a signup view with such a signature (at the time of writing):
def signup(request, signup_form=SignupForm,
template_name='userena/signup_form.html', success_url=None,
extra_context=None):
This means that you can replace the form used by the signup view. To do so, open your urls.py, add what we are going to need at the top:
from userena import views as userena_views
from yourforms import YourSignupForm
Then, find the include the external app’s urls, something like:
url(r'^userena/', include('userena.urls')),
Before that, add your url override:
url(r'^userena/signup/$', userena_views.signup, {'signup_form': YourSignupForm}, name='userena_signup'),
url(r'^userena/', include('userena.urls')),
Now, your custom url definition will be the first to be hit when a visitor hits /userena/signup/. Which means that /userena/signup/ will use YourSignupForm instead of userena’s signup form.
This trick works with any view argument. The ones you should see the most often are:
template_name: lets you change the template name
extra_context: lets you add a dict that will be added to the
context
Almost every view should have these arguments.
Overriding a view
Overriding a view requires to override the url of the view you want to replace. If you want your own signup view to be used, then just override the url:
import yourviews
# ...
url(r'^userena/signup/$', yourviews.yoursignup, name='userena_signup'),
url(r'^userena/', include('userena.urls')),
Decorating a view
Decorating a view is like overriding a view, but reuses the external app’s view. Basically, it’s the same than overriding a view (see above), but your view will look like this
from userena import views as userena_views
def yoursignup(request):
# do stuff before userena signup view is called
# call the original view
response = userena_views.signup(request)
# do stuff after userena signup view is done
# return the response
return response
Forking an app
If you are not familiar with pip and virtualenv first, please read the post about using pip and virtualenv first.
For example:
You installed django-userena as such: pip install django-userena
First you should uninstall it: pip uninstall django-userena
Then go on the app’s github page
Click on the fork button
This will make you a repository with a copy of django-userena
Install it as such: pip install -e
git+git#github.com:your-username/django-userena.git#egg=django-userena
Then you can edit the code in yourenv/src/django-userena
Push your commits
Credits to the post writer!
I think the neatest way to accomplish what you look for would be to fork django-registration, and in your app use the fork instead of the original project.
That being said, you can have a non-email registration in django-registration without changing the code of the app. I've done it by creating a custom registration backend that sets the users as activated upon creation. Here you can see other ways to do the same.
I'm new to Django and in bouncing around the framework over the past few days I haven't been able to figure out how to properly install the django.contrib.auth app in my project.
Well, installing is probably not the right word, but configuring it for my purposes.
What I'm truly hoping to do is extend the built-in classes to simply create registration and login forms, since my User class is working just fine from terminal.
In settings.py I have django.contrib.auth in my INSTALLED_APPS.
I also have installed the Authentication Middleware and Sessions Middleware.
I can also clearly see in Django.contrib.auth.views and Django.contrib.auth.forms where the registration and authentication handlers are.
My problem, it seems, since I'm new to the framework, is properly including these files in my project and generating the HTML forms for registration and login.
(As in, do I need to include these Auth files in my app's forms.py? What do I need to model that hasn't already been modeled for me? And finally, since I can see in Django.contrib.auth.views a need for a registration directory with HTML templates, how can I get these all communicating with each other properly?)
Figured out the problem. Just needed to follow Django's URL Conf conventions. Example: (r'^accounts/login/$', 'django.contrib.auth.views.login'),
James Bennet's django-registration is an excellent helper application used for a common registration / login pattern.