When I am starting my Django project from the login page the url is showing like this:
http://127.0.0.1:8000/login/?next=/
But what i want only this:
http://127.0.0.1:8000/login
What is the way to hide this next parameter appearing to the url?
I have set login url and login redirect urls to the settings.py:
settings.py
LOGIN_URL = '/login/'
LOGIN_REDIRECT_URL = '/'
urls.py
urlpatterns = [
url(r'^$',views.index,name='home'),
url(r'login/$',views.userLogin,name='login'),
]
This behavior is located in the AccessMixin in django.contrib.auth.
If you dislike it - inherit from LoginRequiredMixin and overwrite redirect_field_name to return '' or None. You need to use this mixin afterwards for the views for which you want to enforce login.
You should have a good reason for it. Usually as already mentioned in the comments above this behavior is useful.
Related
I want to have my custom "/login" page. So in settings.py I did a simple LOGIN_URL = '/login'. But before doing it, I want to develop all other more complex pages. I found a simple but very effective hack like this:
urlpatterns = [
# blabla
url(r'^admin/', include(admin.site.urls)),
url(r'^login/$', RedirectView.as_view(
url=reverse_lazy('admin:login'))),
# blabla
]
This means: when the user is not connected he/she is redirected to /login. In the urls, /login is converted to 'admin:login' which is admin/login. This is a "double" redirect. Everthing works fine except this:
origin URL: "/my_jobs"
redirected to "login?next=/my_jobs"
redirected to "/admin/login"
So my problem is that I want do pass again the "next" parameter in the RedirectView. I found a lot about redirection and custom login, but not something about that on stackoverflow (this is not a duplicate).
You can set query_string to True, so that query strings are appended to the URL.
RedirectView(
url=reverse_lazy('admin:login'),
query_string=True,
# You might want to set permanent=False,
# as it defaults to True for Django < 1.9
permanent=False,
)
Note that Django comes with a built in login view. You can enable it by adding the URL pattern and a simple template, which isn't much more work than your code above.
I only want to allow people to sign up or log in with their social account. I have the social sign up and log in working, but I cant figure out how to disable the local sign up.
I've read the docs and this sounds close to what I want
ACCOUNT_FORMS (={})
Used to override forms, for example: {‘login’: ‘myapp.forms.LoginForm’}
It seems like I can make a new sign up form and only include the social log in link, but I was hoping there is any easier way that I'm overlooking. I'm still new to this all so I tend to miss the obvious a lot still.
I also tried changing the code below to False, but that disabled social sign up as well.
allauth.account.adapter.py
def is_open_for_signup(self, request):
"""
Checks whether or not the site is open for signups.
Next to simply returning True/False you can also intervene the
regular flow by raising an ImmediateHttpResponse
"""
return True
Change templates and urlpatterns
You would have to change both the templates (login, signup, etc.) and urlpatterns provided by allauth by default, which relate to the classic signup/login flow using email.
Changing/reducing the available routes via the urlpatterns ensures that only the routes are available that should be there. HTTP error 404 is then shown for any attempt to hack into existing allauth default functionality (related to email) if you do it right.
Changing the templates can ensure that the user interface does not provide what is related to email-based authentication.
No easy option available
Unfortunately, as of today there is no easy switch or setting to simply disable email-based signup and authentication with django-allauth. More details may be on GitHub in future, see:
Issue #1227 ("Social only: disable all local account handling by means of a simple setting")
Issue #345 ("How to disable form login/signup?")
Sample: urls.py
An urls.py like this will work with the current django-allauth (v0.30.0) on Django 1.10:
from django.conf.urls import include, url
from allauth.account.views import confirm_email, login, logout
from allauth.compat import importlib
from allauth.socialaccount import providers
providers_urlpatterns = []
for provider in providers.registry.get_list():
prov_mod = importlib.import_module(provider.get_package() + '.urls')
providers_urlpatterns += getattr(prov_mod, 'urlpatterns', [])
urlpatterns = [
url(r'^auth/', include(providers_urlpatterns)),
url(r'^confirm-email/(?P<key>[-:\w]+)/$', confirm_email, name='account_confirm_email'),
url(r'^login/$', login, name='account_login'),
url(r'^logout/$', logout, name='account_logout'),
url(r'^signup/$', login, name='account_signup'), # disable email signup
]
The solution wasn't what I originally thought. The much easier way to do this, instead of changing the forms, was to change the template and just remove any other options in that template.
My page now correctly only shows social auth and I am happy.
If anyone has a better or more secure answer I'd be open to it. Being new still, I don't know if this is the best solution, but for now it seems great and will mark as answered.
Ok, here is the thing. If you are not using any social account to link to your users, then it's very simple to finish the task you described by simply only include urls you need. However, if you need to use social account to link your users, then you have to include all urls because most third party application will not certify the request from your app. they only accept request from allauth.
from django.urls import path, re_path
from allauth.account import views as accountviews
urlpatterns = [
path('admin/', admin.site.urls),
# remember to comment out the following line since it will
# include all urls from allauth lib
# path('accounts/', include('allauth.urls'))
]
# assume you only want singup page and login page from allauth
urlpatterns += [path("acc/signup/", accountviews.signup, name="account_signup"),
path("acc/login/", accountviews.login, name="account_login")
]
How can I support old and new URI versions both working without breaking the reverse()?
For example, I have:
urlpatterns = patterns('',
url(r'^(old_part|new_part)/other/$', 'some_view'),
)
In this case /old_part/other/ and /new_part/other/ point to the same view but reverse() method fails because it doesn't know how to form link properly.
Also, what if we have url(r'^(old_part|new_part)/other/', include(sub_patterns)) how can it be handled?
Do you have any ideas?
Thanks for your help.
I suppose you are migrating. This means you don't want old url work, you want it to redirect to new url. Probably with 301 HTTP code (permanent redirect).
Having several urls for same content makes your site harder to use and hurts your SEO. Permanent redirect will tell Google and any other search engine to reindex page with new address.
You can do it this way in Django:
from django.views.generic import RedirectView
urlpatterns = patterns('',
url(r'^new_part/other/$', 'some_view'),
url(r'^old_part/other/$',
RedirectView.as_view(url='new_part/other/', permanent=True)),
)
If you need to capture everything with a subpath, you can capture url ending and add it to redirect url this way:
urlpatterns = patterns('',
url(r'^new_part/other/$', include(sub_patterns)),
url(r'^old_part/other/(?P<rest>.*)$',
RedirectView.as_view(url='new_part/other/%(rest)s', permanent=True)),
)
You can use redirect_to generic view in Django 1.4 and earlier.
If you want without a redirect, you could try this
url(r'^(?P<url>old_part|new_part)/other/$', 'some_view', name='some_view'),
Then your view will look like this
def some_view(request, url):
...
Then call reverse like this:
# will return /old_part/other/
reverse('some_view', kwargs={'url': 'old_part'})
# will return /new_part/other/
reverse('some_view', kwargs={'url': 'new_part'})
Just redirect the old urls to the new ones (with a 301 Moved Permanently).
NB : if you really insist on supporting both sets of urls (not a good idea IMHO), you'll have to have two distinct url patterns, and choose which one reverse() should resolve to.
I found a form of information leakage when using the #login_required decorator and setting the LOGIN_URL variable.
I have a site that requires a mandatory login for all content. The problem is that you get redirected to the login page with the next variable set when it's a existing page.
So when not logged in and asking for:
http://localhost:8000/validurl/
You see this:
http://localhost:8000/login/?next=/validurl/
And when requesting an non existing page:
http://localhost:8000/faultyurl/
You see this:
http://localhost:8000/login/
Which reveals some information that I dont want. I thought of overriding the login method, forcing the next to empty and calling 'super' on this subclassed method.
An additional problem is that some of my tests fail without the LOGIN_URL set. they redirect to '/accounts/login/' instead of '/login/'. Hence why I'd like to use the LOGIN_URL but disable the 'auto next' feature.
Anybody that can shed some light on the subject?
Thanx a lot.
Gerard.
You can include this line as the last pattern in your urls.py file. It will re-route urls that do not match any other pattern to the login page.
urlpatterns = patterns('',
...
(r'^(?P<path>.+)$', 'django.views.generic.simple.redirect_to', {
'url': '/login/?next=/%(path)s',
'permanent': False
}),
)
EDIT: To keep raising 404 pages to authenticated users, do the following:
from django.http import Http404, HttpResponseRedirect
def fake_redirect(request, path):
if request.user.is_authenticated:
raise Http404()
else:
return HttpResponseRedirect('/login/?next=/%s' % path)
urlpatterns = patterns('',
...
(r'^(?P<path>.+)$', fake_redirect),
)
For example I can point the url '^/accounts/password/reset/$' to django.contrib.auth.views.password_reset with my template filename in the context but I think need to send more context details.
I need to know exactly what context to add for each of the password reset and change views.
If you take a look at the sources for django.contrib.auth.views.password_reset you'll see that it uses RequestContext. The upshot is, you can use Context Processors to modify the context which may allow you to inject the information that you need.
The b-list has a good introduction to context processors.
Edit (I seem to have been confused about what the actual question was):
You'll notice that password_reset takes a named parameter called template_name:
def password_reset(request, is_admin_site=False,
template_name='registration/password_reset_form.html',
email_template_name='registration/password_reset_email.html',
password_reset_form=PasswordResetForm,
token_generator=default_token_generator,
post_reset_redirect=None):
Check password_reset for more information.
... thus, with a urls.py like:
from django.conf.urls.defaults import *
from django.contrib.auth.views import password_reset
urlpatterns = patterns('',
(r'^/accounts/password/reset/$', password_reset, {'template_name': 'my_templates/password_reset.html'}),
...
)
django.contrib.auth.views.password_reset will be called for URLs matching '/accounts/password/reset' with the keyword argument template_name = 'my_templates/password_reset.html'.
Otherwise, you don't need to provide any context as the password_reset view takes care of itself. If you want to see what context you have available, you can trigger a TemplateSyntax error and look through the stack trace find the frame with a local variable named context. If you want to modify the context then what I said above about context processors is probably the way to go.
In summary: what do you need to do to use your own template? Provide a template_name keyword argument to the view when it is called. You can supply keyword arguments to views by including a dictionary as the third member of a URL pattern tuple.
Strongly recommend this article.
I just plugged it in and it worked
http://garmoncheg.blogspot.com.au/2012/07/django-resetting-passwords-with.html
You just need to wrap the existing functions and pass in the template you want. For example:
from django.contrib.auth.views import password_reset
def my_password_reset(request, template_name='path/to/my/template'):
return password_reset(request, template_name)
To see this just have a look at the function declartion of the built in views:
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/views.py#L74
You can do the following:
add to your urlpatterns (r'^/accounts/password/reset/$', password_reset)
put your template in '/templates/registration/password_reset_form.html'
make your app come before 'django.contrib.auth' in INSTALLED_APPS
Explanation:
When the templates are loaded, they are searched in your INSTALLED_APPS variable in settings.py .
The order is dictated by the definition's rank in INSTALLED_APPS, so since your app come before 'django.contrib.auth' your template were loaded (reference: https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.app_directories.Loader).
Motivation of approach:
I want be more dry and don't repeat for any view(defined by django) the template name (they are already defined in django)
I want a smallest url.py
Another, perhaps simpler, solution is to add your override template directory to the DIRS entry of the TEMPLATES setting in settings.py. (I think this setting is new in Django 1.8. It may have been called TEMPLATE_DIRS in previous Django versions.)
Like so:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
# allow overriding templates from other installed apps
'DIRS': ['my_app/templates'],
'APP_DIRS': True,
}]
Then put your override template files under my_app/templates. So the overridden password reset template would be my_app/templates/registration/password_reset_form.html
The documentation says that there only one context variable, form.
If you're having trouble with login (which is common), the documentation says there are three context variables:
form: A Form object representing the login form. See the forms documentation for more on Form objects.
next: The URL to redirect to after successful login. This may contain a query string, too.
site_name: The name of the current Site, according to the SITE_ID setting.
I was using this two lines in the url and the template from the admin what i was changing to my need
url(r'^change-password/$', 'django.contrib.auth.views.password_change', {
'template_name': 'password_change_form.html'}, name="password-change"),
url(r'^change-password-done/$', 'django.contrib.auth.views.password_change_done', {
'template_name': 'password_change_done.html'
}, name="password-change-done")