Thanks Boris & Allan,
I was able to research the problem further and found that my header was
being set entirely correctly, and the Django csrf middleware does in fact
require both the cookie AND the header to be set. It's not an either/or,
and there is an explicit error message for when either
My way, i use the csrf_token tag on template, an pass it to the view in the
ajax call, using
$.ajax({
url : url,
type : "POST", // http method
data : {'csrfmiddlewaretoken': $('input[name="csrfmiddlewaretoken"]').val(),
'v1':v1,'v2':v2,
}, // data sent with the post r
Você pode criar um arquivo js chamado *ajax_post_config.js* e nele inserir
o seguinte código:
function csrfSafeMethod(method) {
// these HTTP methods do not require CSRF protection
return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}
function getCookie(name) {
var cookieValue
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})
>
I'm sorry, the error was in my PERL code:
$req->content("csrfmiddlewaretoken=$csrfid");
is the correct POST request setting.
On Dec 7, 11:40 am, gentlestone wrote:
> I have a PERL test script for DJANGO connection test. It works on
> Django 1.1 admin login page, but doesn't work on 1.2. The reque
On Fri, Jun 25, 2010 at 6:31 PM, thusjanthan wrote:
> The quick answer is you have to put the following in your template
> right after the declaration:
>
> {% csrf_token %}
>
> Cheers,
> Nathan.
>
And how precisely will that make his browser submit the form in a
manner that django can decipher?
The quick answer is you have to put the following in your template
right after the declaration:
{% csrf_token %}
Cheers,
Nathan.
On Jun 25, 2:48 am, Li Hui wrote:
> When I add enctype="text/plain" to a post form like method="post" enctype="text/plain">, there is a "CSRF verification
> faile
On Fri, Jun 25, 2010 at 10:48 AM, Li Hui wrote:
> When I add enctype="text/plain" to a post form like method="post" enctype="text/plain">, there is a "CSRF verification
> failed." error.
> But when I remove it, all is right.
> Who can tell me why?
>
Because that is not how HTML user agents work.
19 matches
Mail list logo
