Bumps [scrapy](https://github.com/scrapy/scrapy) from 1.8.0 to 1.8.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/scrapy/scrapy/releases">scrapy's releases</a>.</em></p> <blockquote> <h2>1.8.2</h2> <h3>Security bug fixes</h3> <ul> <li> <p>When a <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object with cookies defined gets a redirect response causing a new <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object to be scheduled, the cookies defined in the original <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object are no longer copied into the new <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object.</p> <p>If you manually set the <code>Cookie</code> header on a <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object and the domain name of the redirect URL is not an exact match for the domain of the URL of the original <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object, your <code>Cookie</code> header is now dropped from the new <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object.</p> <p>The old behavior could be exploited by an attacker to gain access to your cookies. Please, see the <a href="https://github.com/scrapy/scrapy/security/advisories/GHSA-cjvr-mfj7-j4j8">cjvr-mfj7-j4j8 security advisory</a> for more information.</p> <p><strong>Note:</strong> It is still possible to enable the sharing of cookies between different domains with a shared domain suffix (e.g. <code>example.com</code> and any subdomain) by defining the shared domain suffix (e.g. <code>example.com</code>) as the cookie domain when defining your cookies. See the documentation of the <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> class for more information.</p> </li> <li> <p>When the domain of a cookie, either received in the <code>Set-Cookie</code> header of a response or defined in a <a href="https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request"><code>Request</code></a> object, is set to a <code>public suffix <https://publicsuffix.org/></code>_, the cookie is now ignored unless the cookie domain is the same as the request domain.</p> <p>The old behavior could be exploited by an attacker to inject cookies from a controlled domain into your cookiejar that could be sent to other domains not controlled by the attacker. Please, see the <a href="https://github.com/scrapy/scrapy/security/advisories/GHSA-mfjm-vh54-3f96">mfjm-vh54-3f96 security advisory</a> for more information.</p> </li> </ul> <h2>1.8.1</h2> <p><strong>Security bug fix:</strong></p> <p>If you use <a href="https://docs.scrapy.org/en/2.5/topics/downloader-middleware.html#module-scrapy.downloadermiddlewares.httpauth"><code>HttpAuthMiddleware</code></a> (i.e. the <code>http_user</code> and <code>http_pass</code> spider attributes) for HTTP authentication, any request exposes your credentials to the request target.</p> <p>To prevent unintended exposure of authentication credentials to unintended domains, you must now additionally set a new, additional spider attribute, <code>http_auth_domain</code>, and point it to the specific domain to which the authentication credentials must be sent.</p> <p>If the <code>http_auth_domain</code> spider attribute is not set, the domain of the first request will be considered the HTTP authentication target, and authentication credentials will only be sent in requests targeting that domain.</p> <p>If you need to send the same HTTP authentication credentials to multiple domains, you can use <code>w3lib.http.basic_auth_header</code> instead to set the value of the <code>Authorization</code> header of your requests.</p> <p>If you <em>really</em> want your spider to send the same HTTP authentication credentials to any domain, set the <code>http_auth_domain</code> spider attribute to <code>None</code>.</p> <p>Finally, if you are a user of <a href="https://github.com/scrapy-plugins/scrapy-splash">scrapy-splash</a>, know that this version of Scrapy breaks compatibility with scrapy-splash 0.7.2 and earlier. You will need to upgrade scrapy-splash to a greater version for it to continue to work.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/scrapy/scrapy/blob/master/docs/news.rst">scrapy's changelog</a>.</em></p> <blockquote> <h2>Scrapy 1.8.2 (2022-03-01)</h2> <p><strong>Security bug fixes:</strong></p> <ul> <li> <p>When a :class:<code>~scrapy.http.Request</code> object with cookies defined gets a redirect response causing a new :class:<code>~scrapy.http.Request</code> object to be scheduled, the cookies defined in the original :class:<code>~scrapy.http.Request</code> object are no longer copied into the new :class:<code>~scrapy.http.Request</code> object.</p> <p>If you manually set the <code>Cookie</code> header on a :class:<code>~scrapy.http.Request</code> object and the domain name of the redirect URL is not an exact match for the domain of the URL of the original :class:<code>~scrapy.http.Request</code> object, your <code>Cookie</code> header is now dropped from the new :class:<code>~scrapy.http.Request</code> object.</p> <p>The old behavior could be exploited by an attacker to gain access to your cookies. Please, see the <code>cjvr-mfj7-j4j8 security advisory</code>_ for more information.</p> <p>.. _cjvr-mfj7-j4j8 security advisory: <a href="https://github.com/scrapy/scrapy/security/advisories/GHSA-cjvr-mfj7-j4j8">https://github.com/scrapy/scrapy/security/advisories/GHSA-cjvr-mfj7-j4j8</a></p> <p>.. note:: It is still possible to enable the sharing of cookies between different domains with a shared domain suffix (e.g. <code>example.com</code> and any subdomain) by defining the shared domain suffix (e.g. <code>example.com</code>) as the cookie domain when defining your cookies. See the documentation of the :class:<code>~scrapy.http.Request</code> class for more information.</p> </li> <li> <p>When the domain of a cookie, either received in the <code>Set-Cookie</code> header of a response or defined in a :class:<code>~scrapy.http.Request</code> object, is set to a <code>public suffix <https://publicsuffix.org/></code>_, the cookie is now ignored unless the cookie domain is the same as the request domain.</p> <p>The old behavior could be exploited by an attacker to inject cookies into your requests to some other domains. Please, see the <code>mfjm-vh54-3f96 security advisory</code>_ for more information.</p> <p>.. _mfjm-vh54-3f96 security advisory: <a href="https://github.com/scrapy/scrapy/security/advisories/GHSA-mfjm-vh54-3f96">https://github.com/scrapy/scrapy/security/advisories/GHSA-mfjm-vh54-3f96</a></p> </li> </ul> <p>.. _release-1.8.1:</p> <h2>Scrapy 1.8.1 (2021-10-05)</h2> <ul> <li> <p><strong>Security bug fix:</strong></p> <p>If you use</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/scrapy/scrapy/commit/ae41acb502e2192d760e450bd2fbea3484faaba7"><code>ae41acb</code></a> Bump version: 1.8.1 → 1.8.2</li> <li><a href="https://github.com/scrapy/scrapy/commit/d2589c74c59603af1c67f6f5416cc6a8c67dd421"><code>d2589c7</code></a> test_unbounded_response: to_unicode → custom six code</li> <li><a href="https://github.com/scrapy/scrapy/commit/efd72b08f9dee3742c18b1847353743cc02138e9"><code>efd72b0</code></a> tests: unicode → to_unicode</li> <li><a href="https://github.com/scrapy/scrapy/commit/c5c2e2c7e998cd41b739667cb95a233100030efb"><code>c5c2e2c</code></a> tests: fix cast (str → unicode)</li> <li><a href="https://github.com/scrapy/scrapy/commit/ed2348de762d9691c50de244d60cee1543c1f070"><code>ed2348d</code></a> CI: Install mock in Python 3.5 with pinned dependencies</li> <li><a href="https://github.com/scrapy/scrapy/commit/919f52fb8f2698faec1f8e44756fc732ded6e8ec"><code>919f52f</code></a> CI: Install mock in Python 3.5</li> <li><a href="https://github.com/scrapy/scrapy/commit/610ce9b96d9d43036c2d9f0bb51a4c62df739fcf"><code>610ce9b</code></a> Fix typo</li> <li><a href="https://github.com/scrapy/scrapy/commit/6c55f7631883e2c8048cc135361c7958ff063c3d"><code>6c55f76</code></a> Stop mixing keyword arguments and ** in function calls</li> <li><a href="https://github.com/scrapy/scrapy/commit/c4b22a5817863321cabc0f7228271d3e4b9dbf68"><code>c4b22a5</code></a> Remove further Python 3 syntax</li> <li><a href="https://github.com/scrapy/scrapy/commit/c0e745e3fd5499f8f44cc6f52d71f77dcd00974a"><code>c0e745e</code></a> Remove Python 3 syntax</li> <li>Additional commits viewable in <a href="https://github.com/scrapy/scrapy/compare/1.8.0...1.8.2">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/adorum/reality/network/alerts). </details>
This issue appears to be discussing a feature request or bug report related to the repository. Based on the content, it seems to be resolved. The issue was opened by dependabot[bot] and has received 1 comments.