Ah, yes, I see now. I was mistaken, too, which added to the confusion.
This tutorial and deformdemo use different methods and have different stacks.
I don't know whether either is wrong, but perhaps just different? Perhaps bits
of each implementation were mixed together during your
Hello Jonathan,
thank you for your message, and sorry for my late answer, I'm seeing
it only now. I've understood the difference by now, having spent a
number of hours on the problem (I'm not a Python or Pyramid newbie,
but I admit I am (or was?) a CSRF newbie).
> The `session.get_csrf_token`
They're not the same at all.
The difference is on purpose.
Janzert is correct, though his description may not necessarily be clear.
The following might make more sense:
The two functions do the following:
pyramid.csrf.get_csrf_token(request)
discern active ICSRFStoragePolicy
invoke
When using a pyramid.session session factory calling
request.session.get_csrf_token seems to **always** be equivalent to using
LegacySessionCSRFStoragePolicy (sort of by definition I suppose).
You can confirm this by looking at the session.get_csrf_token definition in
No, I haven't configured two session factories, one of them is
commented out, so that I can test either.
If I use LegacySessionCSRFStoragePolicy, get_csrf_token(request) and
request.session.get_csrf_token() do return the same value. A look at
the source code shows they are implemented in the same
They are effectively the same.
https://docs.pylonsproject.org/projects/pyramid/en/latest/_modules/pyramid/csrf.html#LegacySessionCSRFStoragePolicy.get_csrf_token
In your code, you have configured two session factories. I assume you get the
CSRF unique to each factory. ¯\_(ツ)_/¯
--steve
On
So, if I follow this line of reasoning, the way to get the same value
as in the template is to use :
from pyramid.csrf import get_csrf_token
print get_csrf_token(request)
and *not* :
print request.session.get_csrf_token()
Le dim. 2 mai 2021 à 19:11, Laurent Daverio a écrit :
>
> OK, I've been
OK, I've been able to nail it down on a simple example : depending on
the CSRF storage policy I use, "request.session.get_csrf_token()"
(called from python or a template) and "get_csrf_token()" (called from
a template) return the same value *or not*.
- no storage policy => ok
-
Hi Mikko, thank you for your reply :)
I don't think I'm doing anything weird there. The problem happens in a
class-based view.
I can see the 'csrf_token' cookie qith the right value, I can display
the same value inside a template by calling get_csrf_token(), but the
value generated inside the
Thank you Steve. I'll have to think about it, not that the code is
secret, just a matter of knowing what to post to be relevant.
Le mer. 28 avr. 2021 à 22:10, Steve Piercy
a écrit :
>
> It's difficult to say without your example. I've been using CSRF as shown in
> the Deform demo without any
It's difficult to say without your example. I've been using CSRF as shown in
the Deform demo without any issues.
--steve
On 4/28/21 10:32 AM, Laurent Daverio wrote:
> Hello List,
>
> I'd like to report a problem I've just encountered, occurring betwen
> Pyramid's CSRF protection and Deform.
Hi Laurent,
>
> The Deform Demo
> (https://deformdemo.pylonsproject.org/pyramid_csrf_demo/) shows how to
> use a deferred value to create hidden field "csrf_token" in the
> generated forms
>
>
> But there's a problem: the token generated that way doesn't have the
> same value as when I
Hello List,
I'd like to report a problem I've just encountered, occurring betwen
Pyramid's CSRF protection and Deform.
Basically, I have a Pyramid 2.0 web app configured along the lines of
the "URL dispatch wiki tutorial"
13 matches
Mail list logo
