id,page,ref,title,content,breadcrumbs,references
changelog:csrf-protection,changelog,csrf-protection,CSRF protection,"Since writable canned queries are built using POST forms, Datasette now ships with  CSRF protection  ( #798 ). This applies automatically to any POST request, which means plugins need to include a  csrftoken  in any POST forms that they render. They can do that like so: 
                 <input type=""hidden"" name=""csrftoken"" value=""{{ csrftoken() }}"">","[""Changelog"", ""0.44 (2020-06-11)""]","[{""href"": ""https://github.com/simonw/datasette/issues/798"", ""label"": ""#798""}]"
internals:internals-csrf,internals,internals-csrf,CSRF protection,"Datasette uses  asgi-csrf  to guard against CSRF attacks on form POST submissions. Users receive a  ds_csrftoken  cookie which is compared against the  csrftoken  form field (or  x-csrftoken  HTTP header) for every incoming request. 
             If your plugin implements a  <form method=""POST"">  anywhere you will need to include that token. You can do so with the following template snippet: 
             <input type=""hidden"" name=""csrftoken"" value=""{{ csrftoken() }}""> 
             If you are rendering templates using the  await .render_template(template, context=None, request=None)  method the  csrftoken()  helper will only work if you provide the  request=  argument to that method. If you forget to do this you will see the following error: 
             form-urlencoded POST field did not match cookie 
             You can selectively disable CSRF protection using the  skip_csrf(datasette, scope)  hook.","[""Internals for plugins""]","[{""href"": ""https://github.com/simonw/asgi-csrf"", ""label"": ""asgi-csrf""}]"