Crawler/Bot activity 触发关键网站文件的删除 - Odoo v9 中的什么代码可能导致此删除发生？
Crawler/Bot activity triggering deletion of critical website files - what code in Odoo v9 could be causing this deletion to occur due?
上下文:
Odoo v9 docker 图像安装在 NginX 反向代理后面，在面向公众的裸域（例如 mydomain.com）上，安装了网站构建器，而不是其他配置或应用程序。
问题:
定期会丢失一个重要文件：
2015-10-30 15:28:28,266 1 INFO db-test werkzeug: 172.17.0.25 - - [30/Oct/2015 15:28:28] "GET /web/content/407-17599c5/website.assets_frontend.js HTTP/1.0" 200 -
2015-10-30 15:28:28,281 1 INFO db-test openerp.addons.base.ir.ir_attachment: _read_file reading /var/lib/odoo/filestore/db-test/e6/e69e06808b908fc0d85ebfea58fbc7df3788e72e
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/openerp/addons/base/ir/ir_attachment.py", line 151, in _file_read
r = open(full_path,'rb').read().encode('base64')
IOError: [Errno 2] No such file or directory: u'/var/lib/odoo/filestore/db-test/e6/e69e06808b908fc0d85ebfea58fbc7df3788e72e'
此文件是一个自动生成的压缩 javascript 文件，其中包含网站运行所需的所有常用 js 资产。因此，网站和应用程序变得无法使用。恢复文件可解决此问题。目前还不清楚是否有其他文件丢失。
到目前为止:
- 仅当域面向公众且可访问时才会发生
（当防火墙关闭只为我服务时，这不会发生
在不同的非索引（例如 Google）域上，这不会
发生。）
- 到目前为止，robots.txt 设置为
"Disallow: /" - 证明这实际上可能需要更长的时间
防止这个问题，但这是一个很长一段时间的问题不
已经发生了。
- 使用 wget 的初始手动爬网不会触发
这个问题 - 虽然这是作为一个新的递归获取进行测试的
出现此问题的域中的当前内容
- 我没有进行重新抓取，也没有请求过时的 url，因此可能无法描绘完整的画面
如需更冗长的背景进入
对此的调查，请参阅：
https://www.odoo.com/forum/help-1/question/updated-how-do-i-prevent-website-common-asset-files-from-constantly-not-being-found-ioerror-errno-2-no-such-file-or-directory-92982
这奇怪是因为域名是 domain.tld 而不是
www.domain.tld?
或者这是 bot/crawler 的怪癖，它触发了它
不应该？
或者这是一个不处理请求的错误 old/expired 或者
未知网址好吗?
或以上的组合？
甚至可能是恶意的activity?
在这一点上，它看起来可能是一个非常令人担忧的安全问题，外部匿名（未登录）用户可以在 odoo 软件中触发灾难性的文件删除。鉴于目前测试的所有变量，这看起来很像问题的根源。如果是，那将是一个重大的安全漏洞。有没有其他人升级到 v9 遇到这个问题？它可能只会发生在已经建立并被 Google 等索引的网站上
任何有助于正确识别和解决此问题的帮助都将不胜感激。
由于某种原因，此记录已从位置 /var/lib/odoo/filestore/db-test/e6/ 或您的 data_dir /filestore/database_name[ 的路径中删除（目前不存在） =12=]
我遇到了同样的错误，所以我只是从 **ir_attachment** table 中删除了该记录。这不是正确的方法，但问题已解决
有两种备份类型，其中一种包括数据库以及转储到 .zip 文件中。
当我使用转储变体进行备份和恢复时，我遇到了这种情况。
这种方式不包括文件存储，因此可以有 ir.attachment 条记录引用文件存储中不存在的文件。
以防万一还有人需要解决这个问题，odoo 代码中存在一个错误，已在以后的版本中修复。此处信息：
上下文:
Odoo v9 docker 图像安装在 NginX 反向代理后面，在面向公众的裸域（例如 mydomain.com）上，安装了网站构建器，而不是其他配置或应用程序。
问题:
定期会丢失一个重要文件：
2015-10-30 15:28:28,266 1 INFO db-test werkzeug: 172.17.0.25 - - [30/Oct/2015 15:28:28] "GET /web/content/407-17599c5/website.assets_frontend.js HTTP/1.0" 200 -
2015-10-30 15:28:28,281 1 INFO db-test openerp.addons.base.ir.ir_attachment: _read_file reading /var/lib/odoo/filestore/db-test/e6/e69e06808b908fc0d85ebfea58fbc7df3788e72e
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/openerp/addons/base/ir/ir_attachment.py", line 151, in _file_read
r = open(full_path,'rb').read().encode('base64')
IOError: [Errno 2] No such file or directory: u'/var/lib/odoo/filestore/db-test/e6/e69e06808b908fc0d85ebfea58fbc7df3788e72e'
此文件是一个自动生成的压缩 javascript 文件，其中包含网站运行所需的所有常用 js 资产。因此，网站和应用程序变得无法使用。恢复文件可解决此问题。目前还不清楚是否有其他文件丢失。
到目前为止:
- 仅当域面向公众且可访问时才会发生 （当防火墙关闭只为我服务时，这不会发生 在不同的非索引（例如 Google）域上，这不会 发生。）
- 到目前为止，robots.txt 设置为 "Disallow: /" - 证明这实际上可能需要更长的时间 防止这个问题，但这是一个很长一段时间的问题不 已经发生了。
- 使用 wget 的初始手动爬网不会触发
这个问题 - 虽然这是作为一个新的递归获取进行测试的
出现此问题的域中的当前内容
- 我没有进行重新抓取，也没有请求过时的 url，因此可能无法描绘完整的画面
如需更冗长的背景进入 对此的调查，请参阅： https://www.odoo.com/forum/help-1/question/updated-how-do-i-prevent-website-common-asset-files-from-constantly-not-being-found-ioerror-errno-2-no-such-file-or-directory-92982
这奇怪是因为域名是 domain.tld 而不是 www.domain.tld?
或者这是 bot/crawler 的怪癖，它触发了它 不应该？
或者这是一个不处理请求的错误 old/expired 或者 未知网址好吗?
或以上的组合？
甚至可能是恶意的activity?
在这一点上，它看起来可能是一个非常令人担忧的安全问题，外部匿名（未登录）用户可以在 odoo 软件中触发灾难性的文件删除。鉴于目前测试的所有变量，这看起来很像问题的根源。如果是，那将是一个重大的安全漏洞。有没有其他人升级到 v9 遇到这个问题？它可能只会发生在已经建立并被 Google 等索引的网站上
任何有助于正确识别和解决此问题的帮助都将不胜感激。
由于某种原因，此记录已从位置 /var/lib/odoo/filestore/db-test/e6/ 或您的 data_dir /filestore/database_name[ 的路径中删除（目前不存在） =12=]
我遇到了同样的错误，所以我只是从 **ir_attachment** table 中删除了该记录。这不是正确的方法，但问题已解决
有两种备份类型，其中一种包括数据库以及转储到 .zip 文件中。
当我使用转储变体进行备份和恢复时，我遇到了这种情况。
这种方式不包括文件存储，因此可以有 ir.attachment 条记录引用文件存储中不存在的文件。
以防万一还有人需要解决这个问题，odoo 代码中存在一个错误，已在以后的版本中修复。此处信息：