CRSFtoken wrong cookie path ?

[abubelinha]

When trying twill-based variations of @sylmorin-gbif script in #1480, a possible new issue about IPT CSRFtoken wrong cookie path has arosen.

If I use Chrome developer tool Network tab and then select login.do to see its Cookies tab, the Request Cookies section shows / as the Path for all cookies (including CSRFtoken), whereas the Response Cookies section always shows "" as the Path for CSRFtoken.
Looks like that might be interfering with IPT login process from some browsers, and might be related to other issues.
This goes far beyond my understanding, so I thank @Cito and paste here his comments taken from twill-tools/twill#11:

I think the reason why it [twill] does not work is that your site [demo IPT] sends a strange cookie path (two quotes instead of an actual path). I guess it only works in some browsers because they silently "correct" the path.
I guess it's the ipt web app or its configuration. The cookie path is set in its CsrfLoginInterceptor class, and something probably is not done right there. It also catches and ignores all Exceptions when setting the path, which does not look clean to me.
#1652 could be related to this.
psf/requests#6245 also looks related to this.
You can tag me [@Cito], but currently I do not have the time to look deeper into these issues.

The crucial issue here is that cookies can have a domain and a path attribute which specify for which domains and URL paths they shall be valid and sent to the server. If the client (the browser or Twill) thinks the path does not match, it does not send the cookie. The behavior if the server sends an invalid path (as ipt is doing) is undefined. Chrome seems to send the cookie anyway in this case, but the RequestsCookieJar does not. Maybe the RequestsCookieJar should be more sloppy as well.

[mike-podolskiy90]

@abubelinha Thank you for reporting the issue.
Something's wrong with the token indeed. I'll investigate