Re: Invalid Referer

Hello Nerijus:

I'm sorry you are having issues. Lets see what we can do.

In message <[email protected]>,
Nerijus Baliunas via Roundup-users writes:
>I upgraded 1.5.1 to 1.6.0, and now when I try to login I get:
>Invalid Referer https://host.name/roundup/support/, /roundup/support/

Check the [tracker] section of config.ini. What is the value of your
"web" variable? I am guessing it is set to a relative path like:

  /roundup/support/

If so set it to:

  https://host.name/roundup/support/

The referer check expects an absolute URL. I thought web was required
to be an absolute URL even in 1.5.1 since it is used in emails.

If you can't use an absolute URL, you can disable the referer header
check by looking in the [web] section of config.ini in your
tracker. Set:

   csrf_enforce_header_referer = logfailure

You can also use the value "no" as documented in the config file.

However, if you use logfailure, you should see a log message like:

 csrf Referer header check failed for user10. Value=/roundup/support/

in your roundup log. I expect the info provided will be the same as
in your error message.

>http://www.roundup-tracker.org/docs/upgrading.html#cross-site-request-forgery-detection-added
>says "If you have forms using the POST method that are not using the
>standard submit routine, you should add the following field to all forms".
>How do I know if my methods are using standard submit routine?

Check your template. You should see something like this:

  <span tal:replace="structure context/submit">submit button</span>

If your form has an html tag with an attribute:

   tal:replace="structure context/submit"

you are using the standard submit routine that adds the appropriate
csrf tokens.

You can also check the forms in your tracker using your browser.  Load
a page and look at the source for the page (or use the developer tools
to inspect the submit button). Look for the submit button. It usually
looks like:

  <input type="submit" ...

If you see a hidden input named @csrf before the submit button that
looks similar to:

   <input type="hidden" name="@csrf"
      value="56b4cddbf477babd0339579d202b67cc4b0c3ff72150e92e20a11f4a3d43a9ee">

then you are all set. (Note there may be an input called @action
between the @csrf and the submit button.)

>Which POST methods (and in which files) should I modify?

Any form that changes data should already use the POST method (that
was a requirement even in 1.5.1). To find those forms, cd to the html
subdirectory of the tracker and use:

   grep -ri 'method=.POST.' .

(assuming you are on linux/unix and not Windows). This will identify
the files and lines in the file with forms that you need to
investigate. When I did the changes, I used grep mode in emacs to
perform the grep and then just used emacs to hop from form to form
fixing things as I went.

If the form has an explicit:

  <input type="submit" ...>

in the form rather than using:

  ...  tal:replace="structure context/submit" ...

you need to add a csrf token as described in the documentation:

    <input name=”@csrf” type=”hidden”
            tal:attributes=”value python:utils.anti_csrf_nonce()”>

>I tried setting srf_enforce_token = no in config.ini, but it did not
>help.

I assume you meant csrf_enforce_token above. That does disable the
need to have an @csrf field as described above. But it is not the
right setting to solve the referer error you described.

I hope this helps.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users