Re: Django : CSRF and variable handling in a view
I guess I'll surrender and go with only the template authenticated
check solution even if it still disturb me a little that the user can
display the sign-up form in a page, then log in on another page and
still be able to sign-up by sending the form.
That's nice to know about the RequestContext ! Also I saw that the
render shortcut was born with Django 1.3, that's really a cool
addition.
Thanks again ;)
Nolhian
On Nov 24, 3:23 pm, Ivo Brodien wrote:
> Hi!
>
> Ah, ok. Now it makes a more sense - index was indeed confusing.
>
> Well in your template I would just make the check and show the form or not.
>
> If your don’t show the form, the user cannot make a POST to the signup view
> since he does not have a valid CSRF token.
>
> Anyway, if the user is logged in there should not be a Link to the signup
> page and even if he enters the signup form url by hand, he will see no form.
>
> Ah, and don’t worry about the RequestContext. I don’t think that it causes
> any important amount of overhead. The processing was done anyways before, so
> its just a matter of making it available to the template or not. And you will
> see, that you will use it often in your templates.
>
> Ivo
> On Nov 24, 2011, at 14:25 , Nolhian wrote
>
>
>
>
>
>
>
> > Hello,
>
> > First of all thanks for your answer !
> > I think that the name I gave "index.html" is causing confusion. In
> > fact that's the first view I created and so the only template I have
> > at the moment and I awkwardly named it index.html, It should be named
> > signup.html or something like that. I'm not looking to handle log in
> > and logout here, just making sure that a logged user cannot sign-up
> > again ( which would be a nonsense and in my opinion a flaw ),this is
> > my signup form view which is located at /subscribe/.
>
> > Is it better with these explications or does the approach I'm taking
> > still feel weird ?
>
> > Nolhian
>
> > On Nov 24, 1:37 pm, Ivo Brodien wrote:
> >> DrBloodMoney is right, It is kind of odd how you are solving the problem
> >> but it might me kind of right depending on what you are trying to do.
>
> >> Considering how most of the websites work you should do this.
>
> >> In all the templates include another template which does this:
>
> >> {% if not user.is_authenticated %}
> >> LINK Login | Link Sign Up
> >> {% else %}
> >> Logged in as username | Link Logout
> >> {% endif %}
>
> >> Logout, Login and Sign Up are handled by different urls/views and not the
> >> index or any other view
>
> >> if you want to make a view available only to authenticated users, use the
> >> @login_required decorator.[2]
>
> >> If you are using the provided django.auth system the views for login,
> >> logout are already there. In the settings you can define some behavior.
>
> >> See the settings LOGIN_REDIRECT_URL, LOGIN_URL, LOGOUT_URL [1]
>
> >> [1]https://docs.djangoproject.com/en/1.3/ref/settings/#login-url
> >> [2]https://docs.djangoproject.com/en/1.3/topics/auth/#the-login-required...
>
> >> On Nov 24, 2011, at 3:31 , Nolhian wrote:
>
> This seems all sorts of wrong to me. Why couldn't the user just log
> out and then post? Seems like an odd workflow, but I don't know your
> business-case here.
>
> >>> Yes the user can just log out and then post but since this is a sign-
> >>> up form it would seem logical to not be able to sign-up if the user is
> >>> logged in which means he already has an account.
>
> You could always control what is shown to the user in the template (to
> limit their ability to use your form to post to the view) with
>
> {% if not user.is_authenticated %}
> SHOW FORM
> {% else %}
> you're logged in so you can't post
> {% endif %}
>
> >>> That's kind of what I'm doing but I still need to check somewhere in
> >>> the view if the user is logged in. If I don't the user can open the
> >>> sign-up form page, then open another page of the site and log in, then
> >>> switch back to the sign-up form page, send the form ( which will be
> >>> validated in the view since there's no checking if the user is
> >>> authenticated or not there ) and successfully sign-up again WHILE
> >>> being logged in. To be able to do that just seems wrong to me.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Django users" group.
> >>> To post to this group, send email to django-users@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> django-users+unsubscr...@googlegroups.com.
> >>> For more options, visit this group
> >>> athttp://groups.google.com/group/django-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.c
Re: Django : CSRF and variable handling in a view
Hi!
Ah, ok. Now it makes a more sense - index was indeed confusing.
Well in your template I would just make the check and show the form or not.
If your don’t show the form, the user cannot make a POST to the signup view
since he does not have a valid CSRF token.
Anyway, if the user is logged in there should not be a Link to the signup page
and even if he enters the signup form url by hand, he will see no form.
Ah, and don’t worry about the RequestContext. I don’t think that it causes any
important amount of overhead. The processing was done anyways before, so its
just a matter of making it available to the template or not. And you will see,
that you will use it often in your templates.
Ivo
On Nov 24, 2011, at 14:25 , Nolhian wrote
> Hello,
>
> First of all thanks for your answer !
> I think that the name I gave "index.html" is causing confusion. In
> fact that's the first view I created and so the only template I have
> at the moment and I awkwardly named it index.html, It should be named
> signup.html or something like that. I'm not looking to handle log in
> and logout here, just making sure that a logged user cannot sign-up
> again ( which would be a nonsense and in my opinion a flaw ),this is
> my signup form view which is located at /subscribe/.
>
> Is it better with these explications or does the approach I'm taking
> still feel weird ?
>
> Nolhian
>
> On Nov 24, 1:37 pm, Ivo Brodien wrote:
>> DrBloodMoney is right, It is kind of odd how you are solving the problem but
>> it might me kind of right depending on what you are trying to do.
>>
>> Considering how most of the websites work you should do this.
>>
>> In all the templates include another template which does this:
>>
>> {% if not user.is_authenticated %}
>> LINK Login | Link Sign Up
>> {% else %}
>> Logged in as username | Link Logout
>> {% endif %}
>>
>> Logout, Login and Sign Up are handled by different urls/views and not the
>> index or any other view
>>
>> if you want to make a view available only to authenticated users, use the
>> @login_required decorator.[2]
>>
>> If you are using the provided django.auth system the views for login, logout
>> are already there. In the settings you can define some behavior.
>>
>> See the settings LOGIN_REDIRECT_URL, LOGIN_URL, LOGOUT_URL [1]
>>
>> [1]https://docs.djangoproject.com/en/1.3/ref/settings/#login-url
>> [2]https://docs.djangoproject.com/en/1.3/topics/auth/#the-login-required...
>>
>> On Nov 24, 2011, at 3:31 , Nolhian wrote:
>>
>>
>>
>>
>>
>>
>>
This seems all sorts of wrong to me. Why couldn't the user just log
out and then post? Seems like an odd workflow, but I don't know your
business-case here.
>>
>>> Yes the user can just log out and then post but since this is a sign-
>>> up form it would seem logical to not be able to sign-up if the user is
>>> logged in which means he already has an account.
>>
You could always control what is shown to the user in the template (to
limit their ability to use your form to post to the view) with
>>
{% if not user.is_authenticated %}
SHOW FORM
{% else %}
you're logged in so you can't post
{% endif %}
>>
>>> That's kind of what I'm doing but I still need to check somewhere in
>>> the view if the user is logged in. If I don't the user can open the
>>> sign-up form page, then open another page of the site and log in, then
>>> switch back to the sign-up form page, send the form ( which will be
>>> validated in the view since there's no checking if the user is
>>> authenticated or not there ) and successfully sign-up again WHILE
>>> being logged in. To be able to do that just seems wrong to me.
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> To post to this group, send email to django-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group
>>> athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
Hello,
First of all thanks for your answer !
I think that the name I gave "index.html" is causing confusion. In
fact that's the first view I created and so the only template I have
at the moment and I awkwardly named it index.html, It should be named
signup.html or something like that. I'm not looking to handle log in
and logout here, just making sure that a logged user cannot sign-up
again ( which would be a nonsense and in my opinion a flaw ),this is
my signup form view which is located at /subscribe/.
Is it better with these explications or does the approach I'm taking
still feel weird ?
Nolhian
On Nov 24, 1:37 pm, Ivo Brodien wrote:
> DrBloodMoney is right, It is kind of odd how you are solving the problem but
> it might me kind of right depending on what you are trying to do.
>
> Considering how most of the websites work you should do this.
>
> In all the templates include another template which does this:
>
> {% if not user.is_authenticated %}
> LINK Login | Link Sign Up
> {% else %}
> Logged in as username | Link Logout
> {% endif %}
>
> Logout, Login and Sign Up are handled by different urls/views and not the
> index or any other view
>
> if you want to make a view available only to authenticated users, use the
> @login_required decorator.[2]
>
> If you are using the provided django.auth system the views for login, logout
> are already there. In the settings you can define some behavior.
>
> See the settings LOGIN_REDIRECT_URL, LOGIN_URL, LOGOUT_URL [1]
>
> [1]https://docs.djangoproject.com/en/1.3/ref/settings/#login-url
> [2]https://docs.djangoproject.com/en/1.3/topics/auth/#the-login-required...
>
> On Nov 24, 2011, at 3:31 , Nolhian wrote:
>
>
>
>
>
>
>
> >> This seems all sorts of wrong to me. Why couldn't the user just log
> >> out and then post? Seems like an odd workflow, but I don't know your
> >> business-case here.
>
> > Yes the user can just log out and then post but since this is a sign-
> > up form it would seem logical to not be able to sign-up if the user is
> > logged in which means he already has an account.
>
> >> You could always control what is shown to the user in the template (to
> >> limit their ability to use your form to post to the view) with
>
> >> {% if not user.is_authenticated %}
> >> SHOW FORM
> >> {% else %}
> >> you're logged in so you can't post
> >> {% endif %}
>
> > That's kind of what I'm doing but I still need to check somewhere in
> > the view if the user is logged in. If I don't the user can open the
> > sign-up form page, then open another page of the site and log in, then
> > switch back to the sign-up form page, send the form ( which will be
> > validated in the view since there's no checking if the user is
> > authenticated or not there ) and successfully sign-up again WHILE
> > being logged in. To be able to do that just seems wrong to me.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
DrBloodMoney is right, It is kind of odd how you are solving the problem but it
might me kind of right depending on what you are trying to do.
Considering how most of the websites work you should do this.
In all the templates include another template which does this:
{% if not user.is_authenticated %}
LINK Login | Link Sign Up
{% else %}
Logged in as username | Link Logout
{% endif %}
Logout, Login and Sign Up are handled by different urls/views and not the index
or any other view
if you want to make a view available only to authenticated users, use the
@login_required decorator.[2]
If you are using the provided django.auth system the views for login, logout
are already there. In the settings you can define some behavior.
See the settings LOGIN_REDIRECT_URL, LOGIN_URL, LOGOUT_URL [1]
[1] https://docs.djangoproject.com/en/1.3/ref/settings/#login-url
[2]
https://docs.djangoproject.com/en/1.3/topics/auth/#the-login-required-decorator
On Nov 24, 2011, at 3:31 , Nolhian wrote:
>> This seems all sorts of wrong to me. Why couldn't the user just log
>> out and then post? Seems like an odd workflow, but I don't know your
>> business-case here.
>
> Yes the user can just log out and then post but since this is a sign-
> up form it would seem logical to not be able to sign-up if the user is
> logged in which means he already has an account.
>
>> You could always control what is shown to the user in the template (to
>> limit their ability to use your form to post to the view) with
>>
>> {% if not user.is_authenticated %}
>> SHOW FORM
>> {% else %}
>> you're logged in so you can't post
>> {% endif %}
>
> That's kind of what I'm doing but I still need to check somewhere in
> the view if the user is logged in. If I don't the user can open the
> sign-up form page, then open another page of the site and log in, then
> switch back to the sign-up form page, send the form ( which will be
> validated in the view since there's no checking if the user is
> authenticated or not there ) and successfully sign-up again WHILE
> being logged in. To be able to do that just seems wrong to me.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
> This seems all sorts of wrong to me. Why couldn't the user just log
> out and then post? Seems like an odd workflow, but I don't know your
> business-case here.
Yes the user can just log out and then post but since this is a sign-
up form it would seem logical to not be able to sign-up if the user is
logged in which means he already has an account.
> You could always control what is shown to the user in the template (to
> limit their ability to use your form to post to the view) with
>
> {% if not user.is_authenticated %}
> SHOW FORM
> {% else %}
> you're logged in so you can't post
> {% endif %}
That's kind of what I'm doing but I still need to check somewhere in
the view if the user is logged in. If I don't the user can open the
sign-up form page, then open another page of the site and log in, then
switch back to the sign-up form page, send the form ( which will be
validated in the view since there's no checking if the user is
authenticated or not there ) and successfully sign-up again WHILE
being logged in. To be able to do that just seems wrong to me.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
> If I don't check anywhere in the view if a user is authenticated, he
> can still use the form to post data and my goal is that if a user is
> authenticated he can't ( in the template if a user is authenticated it
> doesn't display the form ).
> I'm aware that it kind of defy the DRY principle because I have to
> check both in the view and in the template if a user is authenticated
> but I haven't found another way :(
This seems all sorts of wrong to me. Why couldn't the user just log
out and then post? Seems like an odd workflow, but I don't know your
business-case here.
You could always control what is shown to the user in the template (to
limit their ability to use your form to post to the view) with
{% if not user.is_authenticated %}
SHOW FORM
{% else %}
you're logged in so you can't post
{% endif %}
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
Thanks again, Indeed that is nice to know !
Unfortunately I guess I'm still bound to use
request.user.is_authenticated() in my view in this case :
def index(request):
if request.user.is_authenticated():
return render_to_response('index.html',
{'has_account': True})
if request.method == 'POST':
form =
SignupForm(request.POST,error_class=DivErrorList)
if form.is_valid():
return HttpResponseRedirect('/thanks/')
else:
form = SignupForm()
return render(request,'index.html', {'form': form})
If I don't check anywhere in the view if a user is authenticated, he
can still use the form to post data and my goal is that if a user is
authenticated he can't ( in the template if a user is authenticated it
doesn't display the form ).
I'm aware that it kind of defy the DRY principle because I have to
check both in the view and in the template if a user is authenticated
but I haven't found another way :(
In this perspective is it still better at the beginning of my view to
put :
if request.user.is_authenticated():
return render(request,'index.html')
which will pass the whole requestcontext and check in the template :
{% if user.is_authenticated and user.is_active %}
or not pass the whole context like so :
if request.user.is_authenticated():
return render_to_response('index.html',
{'has_account': True})
and check in the template {% if has_account %}. I wonder because it
may be useless here to pass the whole requestcontext and it uses the
same amount of code to write both solutions. What do you think ?
Thanks,
Nolhian
On Nov 23, 2:31 pm, Ivo Brodien wrote:
> no problem.
>
> > I also pass has_account=True in the view if the user is authenticated.
>
> in this case in your template you can just do:
>
> {% if user.is_authenticated and user.is_active %}
>
> That is the advantage of using RequestContext.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
no problem.
> I also pass has_account=True in the view if the user is authenticated.
in this case in your template you can just do:
{% if user.is_authenticated and user.is_active %}
That is the advantage of using RequestContext.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
Okay thanks !
I also pass has_account=True in the view if the user is authenticated.
I noticed that it evaluated it to False if it was missing, I just
wanted to be sure before removing it that it was not considered to be
"the best practice" to pass it anyway :)
On Nov 23, 10:59 am, Ivo Brodien wrote:
> > What about passing a variable set to False ? Should I still pass it
> > like so :
> > return render(request,'index.html', {'form': form,
> > 'has_account':False})
> > Or is it useless to pass it ?
>
> Since you hardcode it to be False, yes it useless also to check in the
> template.
>
> If the variable is missing a "if" in the template will evaluate to False.
>
> If the template is used by other views which could provide has_account =True
> it should be in there, of course!
>
>
>
>
>
>
>
>
>
> > On Nov 23, 5:02 am, DrBloodmoney wrote:
> >> On Tue, Nov 22, 2011 at 6:54 PM, Nolhian wrote:
> >>> Hello,
>
> >>> I've got a subscription form and this view :
>
> >>> def index(request):
> >>> c = RequestContext(request)
> >>> if request.user.is_authenticated():
> >>> return render_to_response('index.html', {'has_account':
> >>> True})
> >>> if request.method == 'POST':
> >>> form = SignupForm(request.POST,error_class=DivErrorList)
> >>> if form.is_valid():
> >>> return HttpResponseRedirect('/thanks/')
> >>> else:
> >>> form = SignupForm()
> >>> return render_to_response('index.html', {'form': form,
> >>> 'has_account':
> >>> False}, c)
>
> >>> 1) In Index.html I have a form with a {% csrf_token %}. If I don't put
> >>> c = RequestContext(request) and add the c into every
> >>> render_to_response I've got a csrf error. Is my view above the right
> >>> way to handle csrf ?
>
> >>> 2) I noticed that instead putting
> >>> c = RequestContext(request) *at the beginning of my view*
> >>> and :
> >>> return render_to_response('index.html', {'form': form, 'has_account':
> >>> False}, c) *at the end of my view*
>
> >>> I could just put this at the end of my view :
>
> >>> c = RequestContext(request, {'has_account': False,'form': form})
> >>> return render_to_response('index.html', c)
>
> >>> Which one it the best approach ?
>
> >>> 3) I also noticed that if i don't pass 'has_account': False to my
> >>> template, nothing changes, it still evaluate it as false in {% if
> >>> has_account %}. Is it best to pass it to the template anyway ?
>
> >>> Thanks in advance,
>
> >>> Nolhian
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Django users" group.
> >>> To post to this group, send email to django-users@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> django-users+unsubscr...@googlegroups.com.
> >>> For more options, visit this group
> >>> athttp://groups.google.com/group/django-users?hl=en.
>
> >> Just use the render [1] shortcut. It'll put the RequestContext in for you.
>
> >> [1]https://docs.djangoproject.com/en/1.3/topics/http/shortcuts/#render
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
> What about passing a variable set to False ? Should I still pass it
> like so :
> return render(request,'index.html', {'form': form,
> 'has_account':False})
> Or is it useless to pass it ?
Since you hardcode it to be False, yes it useless also to check in the template.
If the variable is missing a "if" in the template will evaluate to False.
If the template is used by other views which could provide has_account =True it
should be in there, of course!
>
>
> On Nov 23, 5:02 am, DrBloodmoney wrote:
>> On Tue, Nov 22, 2011 at 6:54 PM, Nolhian wrote:
>>> Hello,
>>
>>> I've got a subscription form and this view :
>>
>>> def index(request):
>>>c = RequestContext(request)
>>>if request.user.is_authenticated():
>>>return render_to_response('index.html', {'has_account':
>>> True})
>>>if request.method == 'POST':
>>>form = SignupForm(request.POST,error_class=DivErrorList)
>>>if form.is_valid():
>>>return HttpResponseRedirect('/thanks/')
>>>else:
>>>form = SignupForm()
>>>return render_to_response('index.html', {'form': form, 'has_account':
>>> False}, c)
>>
>>> 1) In Index.html I have a form with a {% csrf_token %}. If I don't put
>>> c = RequestContext(request) and add the c into every
>>> render_to_response I've got a csrf error. Is my view above the right
>>> way to handle csrf ?
>>
>>> 2) I noticed that instead putting
>>> c = RequestContext(request) *at the beginning of my view*
>>> and :
>>> return render_to_response('index.html', {'form': form, 'has_account':
>>> False}, c) *at the end of my view*
>>
>>> I could just put this at the end of my view :
>>
>>> c = RequestContext(request, {'has_account': False,'form': form})
>>> return render_to_response('index.html', c)
>>
>>> Which one it the best approach ?
>>
>>> 3) I also noticed that if i don't pass 'has_account': False to my
>>> template, nothing changes, it still evaluate it as false in {% if
>>> has_account %}. Is it best to pass it to the template anyway ?
>>
>>> Thanks in advance,
>>
>>> Nolhian
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> To post to this group, send email to django-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group
>>> athttp://groups.google.com/group/django-users?hl=en.
>>
>> Just use the render [1] shortcut. It'll put the RequestContext in for you.
>>
>> [1]https://docs.djangoproject.com/en/1.3/topics/http/shortcuts/#render
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
So :
return render(request,'index.html', {'form': form})
instead of ( in my 2nd question ) :
c = RequestContext(request, {'has_account': False,'form': form})
return render_to_response('index.html', c)
That answers my two first questions. Thanks :)
What about passing a variable set to False ? Should I still pass it
like so :
return render(request,'index.html', {'form': form,
'has_account':False})
Or is it useless to pass it ?
On Nov 23, 5:02 am, DrBloodmoney wrote:
> On Tue, Nov 22, 2011 at 6:54 PM, Nolhian wrote:
> > Hello,
>
> > I've got a subscription form and this view :
>
> > def index(request):
> > c = RequestContext(request)
> > if request.user.is_authenticated():
> > return render_to_response('index.html', {'has_account':
> > True})
> > if request.method == 'POST':
> > form = SignupForm(request.POST,error_class=DivErrorList)
> > if form.is_valid():
> > return HttpResponseRedirect('/thanks/')
> > else:
> > form = SignupForm()
> > return render_to_response('index.html', {'form': form, 'has_account':
> > False}, c)
>
> > 1) In Index.html I have a form with a {% csrf_token %}. If I don't put
> > c = RequestContext(request) and add the c into every
> > render_to_response I've got a csrf error. Is my view above the right
> > way to handle csrf ?
>
> > 2) I noticed that instead putting
> > c = RequestContext(request) *at the beginning of my view*
> > and :
> > return render_to_response('index.html', {'form': form, 'has_account':
> > False}, c) *at the end of my view*
>
> > I could just put this at the end of my view :
>
> > c = RequestContext(request, {'has_account': False,'form': form})
> > return render_to_response('index.html', c)
>
> > Which one it the best approach ?
>
> > 3) I also noticed that if i don't pass 'has_account': False to my
> > template, nothing changes, it still evaluate it as false in {% if
> > has_account %}. Is it best to pass it to the template anyway ?
>
> > Thanks in advance,
>
> > Nolhian
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
>
> Just use the render [1] shortcut. It'll put the RequestContext in for you.
>
> [1]https://docs.djangoproject.com/en/1.3/topics/http/shortcuts/#render
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django : CSRF and variable handling in a view
On Tue, Nov 22, 2011 at 6:54 PM, Nolhian wrote:
> Hello,
>
> I've got a subscription form and this view :
>
> def index(request):
> c = RequestContext(request)
> if request.user.is_authenticated():
> return render_to_response('index.html', {'has_account': True})
> if request.method == 'POST':
> form = SignupForm(request.POST,error_class=DivErrorList)
> if form.is_valid():
> return HttpResponseRedirect('/thanks/')
> else:
> form = SignupForm()
> return render_to_response('index.html', {'form': form, 'has_account':
> False}, c)
>
> 1) In Index.html I have a form with a {% csrf_token %}. If I don't put
> c = RequestContext(request) and add the c into every
> render_to_response I've got a csrf error. Is my view above the right
> way to handle csrf ?
>
> 2) I noticed that instead putting
> c = RequestContext(request) *at the beginning of my view*
> and :
> return render_to_response('index.html', {'form': form, 'has_account':
> False}, c) *at the end of my view*
>
> I could just put this at the end of my view :
>
> c = RequestContext(request, {'has_account': False,'form': form})
> return render_to_response('index.html', c)
>
> Which one it the best approach ?
>
> 3) I also noticed that if i don't pass 'has_account': False to my
> template, nothing changes, it still evaluate it as false in {% if
> has_account %}. Is it best to pass it to the template anyway ?
>
> Thanks in advance,
>
> Nolhian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
Just use the render [1] shortcut. It'll put the RequestContext in for you.
[1] https://docs.djangoproject.com/en/1.3/topics/http/shortcuts/#render
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
