Hi,
I get the same issue recently, I find that my cache system will store the
csrf_token, however, when user logout, and try to login again, it will be
csrf failed, because the new csrf_token is different from the old one
stored in the cache. Yes , this is just my guess.
I have searched Django doc, and Mezzanine, get no help.
At last, I tried to use the template tag "never cache", will it makes
success.
After look into this topic, I finally find the origin method is add
nevercache tag too.
This is fields_for.html
{% load mezzanine_tags %}
{% nevercache %}
<input type="hidden" name="referrer" value="{{ request.META.HTTP_REFERER
}}">
{% csrf_token %}
{% endnevercache %}
{% for field in form_for_fields %}
{% if field.is_hidden %}
{{ field }}
{% else %}
<div class="form-group input_{{ field.id_for_label }} {{ field.field.type }}
{% if field.errors %} has-error{% endif %}">
{% if field.label %}<label class="control-label" for="{{ field.auto_id
}}">{{ field.label }}</label>{% endif %}
{{ field }}
{% if field.errors %}
<p class="help-block">
{% for e in field.errors %}
{% if not forloop.first %} / {% endif %}{{ e }}
{% endfor %}
</p>
{% elif field.help_text %}
<p class="help-block">{{ field.help_text }}</p>
{% endif %}
</div>
{% endif %}
{% endfor %}
On Thursday, March 6, 2014 at 4:01:22 AM UTC+8, Stephen McDonald wrote:
>
> Ah so potentially you just need to add the nevercache tag around the csrf
> token? That would be a relief to know it all works, please let us know.
>
>
> On Thu, Mar 6, 2014 at 4:25 AM, <[email protected] <javascript:>>
> wrote:
>
>>
>> Thanks for the answer. You are entirely right. I had forgotten that I
>> overrode mezzanine's account forms as per the instructions here:
>>
>> http://mezzanine.jupo.org/docs/frequently-asked-questions.html#where-are-all-the-templates-i-can-modify
>>
>>
>>
>> ...and the issue only showed up when caching was turned on in a 'real'
>> environment.
>>
>> Jennifer
>>
>>
>> On Tuesday, March 4, 2014 3:24:56 PM UTC-8, Stephen McDonald wrote:
>>
>>> There are a few moving parts here, my guess is something failing in the
>>> last of these:
>>>
>>> By default in Mezzanine, forms use the "fields_for" template tag, which
>>> is just a helper for rendering forms: https://github.com/
>>> stephenmcd/mezzanine/blob/master/mezzanine/core/templates/includes/form_
>>> fields.html
>>>
>>> You'll see at the top of its template, it uses the "nevercache" tag
>>> which is fairly self explanatory - it's wrapped around the csrf token so
>>> that it's never cached.
>>>
>>> Then finally you'll see in both phases of the caching middleware,
>>> special handling of the csrf token is required:
>>>
>>> https://github.com/stephenmcd/mezzanine/blob/master/
>>> mezzanine/core/middleware.py#L169-L181
>>> https://github.com/stephenmcd/mezzanine/blob/master/
>>> mezzanine/core/middleware.py#L210-L213
>>>
>>> It's likely that last part is somehow incompatible with LiveServerTestCase
>>> - I personally haven't used that before, but with regular Django test cases
>>> I've experienced a lot of differences in how sessions, request objects and
>>> everything related, actually work, compared to an actual running site.
>>>
>>> My advice would be to first verify these forms actually work for you in
>>> production, so that you can isolate this issue down to testing only, and
>>> then unless you're feeling particularly adventurous, disable caching for
>>> those particular tests that are failing - I understand there's a decorator
>>> in Django for modifying settings per test, but the name escapes me.
>>>
>>> Good luck!
>>>
>>>
>>>
>>> On Wed, Mar 5, 2014 at 9:48 AM, <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using LiveServerTestCase, as described here
>>>> <http://chimera.labs.oreilly.com/books/1234000000754/ch17.html#_getting_the_ft_to_run_the_management_on_the_server>,
>>>>
>>>> to automate remote staging testing my site which uses mezzanine 3.0.9.
>>>> The
>>>> automated tests involve logging and out different users, sometimes quite
>>>> rapidly. When caching is turned on as per the settings in
>>>> live_settings.py, I get CSRF errors on login. If I turn off caching to
>>>> memcache, I don't get the errors.
>>>>
>>>> I see that the UpdateCache middleware will go to cache if the user is
>>>> anonymous. At the time the user fills out the login form, they are
>>>> anonymous.... so therefore the login page must be cached, which is causing
>>>> my CSRF failures (?). Unless I'm missing something, this is also true for
>>>> the signup page. It seems like this could be a problem if people submit,
>>>> say, a login or signup form with errors, that then happens to get cached
>>>> and shown to the next user.
>>>>
>>>> Shouldn't there be a strategy to not cache these forms?
>>>>
>>>> Jennifer
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Mezzanine Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>
>>>
>>> --
>>> Stephen McDonald
>>> http://jupo.org
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Stephen McDonald
> http://jupo.org
>
--
You received this message because you are subscribed to the Google Groups
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
