I have a django application with an angular front-end. When from the front-end I try to send a request for passwordReset, I get the following error:
Reverse for 'password_reset_confirm' with arguments '()' and keyword
arguments '{u'uidb64': 'MTE', u'token': u'3z4-eadc7ab3866d7d9436cb'}'
not found. 0 pattern(s) tried: []
Its a POST request going to http://127.0.0.1:8080/rest-auth/password/reset/
Following is what my urls.py looks like:
from django.conf.urls import patterns, include, url
from django.contrib import admin
urlpatterns = patterns('',
url(r'^admin/', include(admin.site.urls)),
url(r'^rest-auth/', include('rest_auth.urls')),
url(r'^rest-auth/registration/', include('rest_auth.registration.urls')),
url(r'^account/', include('allauth.urls'))
)
I also was having this problem, and found this github issue it said we need to add
url(r'^', include('django.contrib.auth.urls')),
on the urlpatterns.
As stated there it says that The PasswordReset view depends on django.contrib.auth.views.password_reset_confirm view.
As Roar Skullestad pointed out, the problem is with the default email template, which tries to resolve URL by reversing viewname "password_reset_confirm", which is undefined.
It is enough to register a viewname "password_reset_confirm" with a custom route and then default email template rendering will work fine.
You can register viewname with custom route by adding a path to urls.py:
urlpatterns = [
...,
path('password-reset/<uidb64>/<token>/', empty_view, name='password_reset_confirm'),
]
password-reset - custom route that password reset confirmation view. If you have SPA (Angular) - it will be the URL of your SPA view (such as the route to Angular component) that will handle the password reset.
This is the URL that will be resolved and embedded in the email. For this example it will be something like:
http://my-spa.com/app-name/password-reset/Nw/51v-490d4b372ec930e49049/
empty_view - in case of SPA (Angular), you don't really need server-side implementation, because the front end will actually handle this route. I used this implementation of a view, but it can be anything else:
from django.http import HttpResponse
def empty_view(request):
return HttpResponse('')
And since I'm using Angular, this is the route for my Angular component:
{
path: 'password-reset/:uid/:token',
component: PasswordRecoveryComponent
}
For me the problem was this line in site-packages/django/contrib/admin/templates/registration/password_reset_email.html:
{{ protocol }}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
From what I understand the problem is caused by reverse lookup not working for this line in contrib/auth/urls.py:
url(r'^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
'django.contrib.auth.views.password_reset_confirm',
name='password_reset_confirm'),
My (at least temporarily) solution was to override the template and hardcode the reverse lookup part of the url for the link in the email.
The path to the new template is specified in settings.py:
TEMPLATE_DIRS =(
"/absolute/path/to/my/templates/directory",
)
Since I am using angular front end, I also changed the link so that it triggers password reset confirmation via the angular client:
{{ protocol }}://{{ domain }}/#/passwordResetConfirm/{{ uid }}/{{ token }}
#AbimaelCarrasquillo's solutions works but you probably do not want to expose those endpoints as #dpstart mentioned in the comments.
I solved this by overriding the PasswordResetSerializer of rest-auth and simply replacing the reset form:
password_reset_form_class = PasswordResetForm
from the internal django.contrib.auth.forms.PasswordResetForm to allauth.account.forms.ResetPasswordForm
Make sure to add the following to your settings:
REST_AUTH_SERIALIZERS = {
'PASSWORD_RESET_SERIALIZER':'path.to.PasswordResetSerializer'
}
For those who are still struggling with this issue, I found that the reverse look up internal view looks for reverse lookup within the core project urls and not within any application. It could work within application with some tweak, but I am not sure. But it works creating the reset urls directly on core project urls.py
{
path(r'password_reset/', PasswordResetView.as_view(template_name='password_reset_form.html'), name='password_reset'),
path(r'password_reset_done/', PasswordResetDoneView.as_view(template_name='password_reset_done.html'), name='password_reset_done'),
path(r'password_reset_confirm/<uidb64>/<token>/', PasswordResetConfirmView.as_view(template_name='password_reset_confirm.html'), name='password_reset_confirm'),
path(r'password_reset_complete/', PasswordResetCompleteView.as_view(template_name='password_reset_complete.html'), name='password_reset_complete'),
}
Well I was also facing this problem. Every time I entered my email and pressed the button it took me to NoReverseMatch url, and I am using:
re_path(r'^password-reset/confirm/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
TemplateView.as_view(template_name="password_reset_confirm.html"),name='password_reset_confirm')
(url is not used to match regex in django anymore re_path is used)
My solution is to change the regex a little bit because the "csrf token" is longer than 20 words – that's why I was getting an error and you should try the same.
re_path(r'^password-reset/confirm/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,40})/$',
TemplateView.as_view(template_name="password_reset_confirm.html"),
name='password_reset_confirm')
You can either use + (in regex it means one or more) or {1,40} (in regex it means match from 1 to 40)
Add this to your project url.py file
url(r'^o/', include('oauth2_provider.urls', namespace='oauth2_provider')),
url('', include('social.apps.django_app.urls', namespace='social')),
Check out the FAQ: It explains this error and how to fix it. It references you to the demo program which contains:
# this url is used to generate email content
url(r'^password-reset/confirm/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$',
TemplateView.as_view(template_name="password_reset_confirm.html"),
name='password_reset_confirm'),
My solution was to override the email template that calls the reverse of "password_reset_confirm". Make sure email template sends a URL to your frontend app with the UID and Token in the URL (instead of trying to reverse "password_reset_confirm").
Your frontend's route should take the URL, parse it and then with the updated user's password and send it back as an API call to your backend to confirm.
I resolved this issue by moving these:
path('reset_password/', auth_views.PasswordResetView.as_view(), name='password_reset'),
path('reset/<uidb64>/<token>/', auth_views.PasswordResetConfirmView.as_view(), name='password_reset_confirm'),
path('reset_password_sent/', auth_views.PasswordResetDoneView.as_view(), name='password_reset_done'),
path('reset_password_complete/', auth_views.PasswordResetCompleteView.as_view(), name='password_reset_complete'),
from accounts/urls.py to yourProjectName/urls.py.
I guess that path('', include("accounts.urls")), was causing the problem.
I have a headless backend, so adding or renaming URLs only for this was not a good option.
The issue is on the email template, you can override it. Just take care that you have the correct path on the settings.
In my case I have all this logic inside users app. So I have something like this.
users/templates/registration/password_reset_email.html
Inside this template I have a new custom message without the reverse URL call.
If you need more than just override the template, or maybe you need to send additional data to the template. You must override the serializer also. To do that you have to create your new serializer
from dj_rest_auth.serializers import PasswordResetSerializer as RestPasswordResetSerializer
class PasswordResetSerializer(RestPasswordResetSerializer):
def get_email_options(self):
return {
'html_email_template_name': 'registration/password_reset_email_html.html', # if you want to use an HTML template you can declare here
'extra_email_context': {'custom_key': 'custom value for my template',}
}
and add to settings.
REST_AUTH_SERIALIZERS = {
'PASSWORD_RESET_SERIALIZER':'path.to.PasswordResetSerializer'
}
On the serializer you can add custom validation if needed also.
In your views.py, if you have set a token, pass it along with the path similar to:
path('resetpassword_validate/<uidb64>/<token>/', views.resetpassword_validate, name='resetpassword_validate'),
Related
I'm looking for a way to redirect any url that start with /D/ to the same URL with lowercased /d/.
/D/<anything_including_url_params>
to
/d/<anything_including_url_params>
I literally only want to redirect urls that start with /D/ - not /DABC/ etc...
The suffix can also be empty, eg. /D/ > /d/
Is there a way to do that in Django? It is for a third-party app with urls included in projects urls.
The alternative is to use re_path and change:
path("d/", include(...))
to
re_path(r"^[dD]/$", include(...))
but I'd rather do a redirect instead of this.
You can make a view that directs with:
# some_app/urls.py
from django.views.generic import RedirectView
# …
urlpatterns = [
path('d/', include(…)),
path(
'D/<path:path>',
RedirectView.as_view(
url='/d/%(path)s', query_string=True, permanent=True
),
),
]
Note that a redirect will however always result in a GET request, so even if the original request to D/something is a POST request for example, it will make a GET request to d/something.
Any reason why you can't use a RedirectView at all?
As per the docs:
https://docs.djangoproject.com/en/4.1/ref/class-based-views/base/#redirectview
You can register this as the literal /D/ but redirect to /d/ using the view name and passing on and args or kwargs.
I have an issue where I try to go to my redirect page and get a NoReverseMatch when though the URL is there? Any idea how to fix this?
I have checked that the "schema" url works and it correctly supplies the openapi schema, but the other page simply can't understand the url.
URLS:
urlpatterns = [
path("schema/", SpectacularAPIView.as_view(), name="schema"),
# Optional UI:
path("docs/", SpectacularSwaggerView.as_view(url_name="schema"), name="swagger-ui"),
]
Errors:
For reverse url pathing, you have to use {% url api:schema %}. It's specified as namespace next to include('api.urls') or inside app urls, just above urlpatterns - like app_name = "api".
There is a complex app (not possible to just paste the code). Going to try to explain.
Django
There is a urls.py file from the native Django app. The urlpatterns defines and register its urls. The ^foo/ defines a group of related urls and the foonamepsace.
urlpatterns = patterns('',
...
url(r'^foo/', include('foo.urls', namespace='foonamespace')),
...
Now there is a method generate_report which does some logic inside and then uses render_to_string to return the HTML:
def generate_report(..):
...
return render_to_string('foo/foo_report.html', args)
Everything works inside the app, the url get reversed successfully.
Django Rest Framework (DRF)
Now there is a DRF implementation and one of its resources is supposed to return a report in a binary format.
class PDFReportViewSet(APIView):
renderer_classes = (BinaryFileRenderer, )
def get(..):
...
pdf = generate_report() # <-- fails with NoReverseMatch
...
return response
Problem
The ViewSet calls the generate_report, however one gets an error when trying to parse the HTML:
NoReverseMatch: foonamespace' is not a registered namespace
Question
Any clues why DRF cannot reverse the namespcae/url from the the core of Django app? How to make sure DRF can reverse a namespace from the core urls.py urlpattern?
Added
After investigation, inside the foo_report.html any usage of the url, for example {% url 'foonamespace:123' %} or {% url 'barnamespace:123' %} produces the error - only if ran from the DRF (running the same page using native Django works fine).
URLS
foo.urls.py
from django.conf.urls import patterns, url
from foo.views import (FooListView, FooDetailView...)
urlpatterns = patterns('',
url(r'^$', FooListView.as_view(), name='foo_list'),
url(r'^(?P<pk>\d+)/$', FooDetailView.as_view(), name='foo_details'),
Important note. The app is served at some.domain.com/, while the REST is served from some.domain.com/rest. So may be this way /rest just don't include anything because it is a parent of the root (which includes the foo.urls.py)
I was managed to resolve my issue with the help from #dirkgroten. It was difficult to see the problem without looking at the source code.
Solution
Updated the routers.py file:
urlpatterns = router.urls
urlpatterns += patterns('',
url(r'^foo/', include('foo.urls', namespace='foonamespace')),
)
Explanation
Basically, the app was serve from the root url / while the rest was served from /rest. The DRF router simply didn't include any of the root routes. Adding them manually like it is shown in solution resolved the problem and made foonamespace visible for all DRF elements.
I have a very simple Django Rest Framework application, my urls.py looks like the following
router = routers.DefaultRouter()
router.register(r'activity-list', activities.views.ArticleViewSet)
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^api/', include(router.urls, namespace='api')),
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
# Base/default URL, when all else fails
urlpatterns += [
url(r'', TemplateView.as_view(template_name='index.html')),
]
When I run the url http://127.0.0.1:8000/api/activity-list, the route that comes from the DRF router never gets reached. The server always seems to give precedence to the default URL, and index.html is always rendered.
However, if I change the Default URL to:
# Base/default URL, when all else fails
urlpatterns += [
url(r'BLABLABLA', TemplateView.as_view(template_name='index.html')),
]
Only then are the DRF routes reachable. This is what makes me think it's a precedence issue. The DRF routes are working, they just always get beaten by the default URL.
I've tried variants suggested in the DRF docs, without luck, such as :
Moreover, /admin works fine, which is why I suspect that it has to do with the DRF router in particular.
But the same thing keeps happening. How can I make my DRF routes reachable while maintaining a default route for the server to land on?
Update: So I've found that adding a trailing slash to the api URL causes it to work. This has led me to these two (1 and 2) questions.
Finally figured it out. According to the DRF docs:
By default the URLs created by SimpleRouter are appended with a
trailing slash. This behavior can be modified by setting the
trailing_slash argument to False when instantiating the router. For
example:
router = SimpleRouter( trailing_slash = False )
Having set this as the setting of the router and transformed my route to r'activity-list', it now works with or without the trailing slash.
You will have to learn url dispatcher in django. Your default url's and DRF route's url's pattern is same, and default url is on top of the urlpatterns thus that url is getting triggered.
How Django processes a request
I am trying to learn Django and I am currently stuck in an issue.
I created an app Contact and run the server, I get the error.
The error page displayed by server:
The urls.py file in the app Contact
urls.py in conatct
When the pattern in urls.py is
urlpatterns =[url(r'^$', views.form, name ='form')]
it works properly, but not with other pattern shown in the picture
Your help would be greatly appreciated.
The Page not found error message tells you what went wrong: For the URL (/contact) you requested, Django was unable to find a suitable view. Because you have debugging enabled, you get some information, including a list of registered views.
First things first: You probably have url(r'^contact/', include('contact.urls')) somewhere in your top level urls.py. This makes the URLs defined in the contact/urls.py available under the prefix /contact.
With
urlpatterns = [
url(r'^form/', views.form, name='form'),
]
in contact/urls.py you are telling Django that you want urls starting with contact/form/ to be handled by views.form.
Consequently, when you access http://localhost:8000/contact/ in your browser, there is no view associated with that URL, hence the 404. Your view is reacting to to http://localhost:8000/contact/form, not http://localhost:8000/contact.
When you change the URL pattern to
urlpatterns = [
url(r'^$', views.form, name='form'),
]
you modify the URL views.form reacts to.