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 ! A
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 i
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 loo
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_authentic
> 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 us
> 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 bec
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})
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 G
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 w
> 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 missi
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 ? Sho
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})
>
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 = Signup
13 matches
Mail list logo