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` method is really a helper function for Pyramid > and add-ons to have a standard interface for stashing a CSRF token in the > session. > it might be worth changing those interface names to have leading underscores, > so the public doesn't rely on them. Or maybe add a warning docstring that > `pyramid.csrf.get_csrf_token` should be used by developers. Actually, when I set out upgrading my code to make it compatible with Pyramid 2.x, I started with one of the official tutorials (SQLAlchemy + URL dispatch wiki tutorial), which says (https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/tutorials/wiki2/definingviews.html#csrf-protection): - Use CookieCSRFStoragePolicy - Add a hidden field with "get_csrf_token()" in your templates So, I was led to believe it was the right way. Erroneously, apparently... Thanks for the clarification, Laurent. Le jeu. 13 mai 2021 à 00:34, 'Jonathan Vanasco' via pylons-discuss <[email protected]> a écrit : > > 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 {ICSRFStoragePolicy.get_csrf_token()} > > request.session.get_csrf_token() > invoke {self.get_csrf_token()} > > Because of that difference, the following happens. > > 1. when using `LegacySessionCSRFStoragePolicy`, `SessionCSRFStoragePolicy`, > or `None` (which is one of those IIRC): > a) pyramid.csrf.get_csrf_token always uses the Session > b) request.session.get_csrf_token is just a shortcut to the above > > 2. when using `CookieCSRFStoragePolicy`: > a) pyramid.csrf.get_csrf_token always uses the dedicated Session > cookie, as you instructed it to. > b) request.session.get_csrf_token is referencing a csrf_token within > the session itself. Pyramid is not configured to ever look in the session for > a csrf, because you told it to use a dedicated session cookie. > > The `session.get_csrf_token` method is really a helper function for Pyramid > and add-ons to have a standard interface for stashing a CSRF token in the > session. it might be worth changing those interface names to have leading > underscores, so the public doesn't rely on them. Or maybe add a warning > docstring that `pyramid.csrf.get_csrf_token` should be used by developers. > > In any event, you are getting different results because you are telling > pyramid to use a cookie for the csrf token, then using one method that > queries that cookie (correct value!) and a second method that queries the > active session for a token -- which is not tied to the pyramid csrf system in > any way. > On Sunday, May 2, 2021 at 6:14:47 PM UTC-4 Steve Piercy wrote: >> >> 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 5/2/21 10:25 AM, Laurent Daverio wrote: >> > 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 <[email protected]> a écrit : >> >> >> >> 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 >> >> - LegacySessionCSRFStoragePolicy => ok >> >> - CookieCSRFStoragePolicy => ko >> >> >> >> I'm attaching my example, I called it "onefile.py", although I needed >> >> two files actually (one python file + one mako template). Sorry ;) >> >> >> >> Le mer. 28 avr. 2021 à 22:32, Laurent Daverio <[email protected]> a écrit >> >> : >> >>> >> >>> 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 >> >>> <[email protected]> a écrit : >> >>>> >> >>>> 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. >> >>>>> >> >>>>> Basically, I have a Pyramid 2.0 web app configured along the lines of >> >>>>> the "URL dispatch wiki tutorial" >> >>>>> (https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/tutorials/wiki2/authentication.html), >> >>>>> with some Deform forms in it. >> >>>>> >> >>>>> 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 directly call get_csrf_token() in a template. >> >>>>> >> >>>>> As I don't have the time/energy to fully investigate the problem right >> >>>>> now, I think I will just use a workaround: as I'm using Diazo as a >> >>>>> theming engine (awesome tech, btw), I think I will add a rule to >> >>>>> inject the token into every form. Should work. >> >>>>> >> >>>>> Still, I wanted to take the time to report the problem, in case it >> >>>>> could be useful. >> >>>>> >> >>>>> Laurent. >> >>>>> >> >>>> >> >>>> -- >> >>>> You received this message because you are subscribed to the Google >> >>>> Groups "pylons-discuss" group. >> >>>> To unsubscribe from this group and stop receiving emails from it, send >> >>>> an email to [email protected]. >> >>>> To view this discussion on the web visit >> >>>> https://groups.google.com/d/msgid/pylons-discuss/44979a98-12ae-239e-8478-c2323aecfaf1%40gmail.com. >> > >> > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/58dd5c50-8c8a-442f-a2b1-2b6f1587d31an%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAB7cU6w7ubumEAtvYK%3Dbr4uQxGxo60C5Np%3DeSo7udNPy7GKTRA%40mail.gmail.com.
