Open Watilin opened 6 years ago
Thank you for your exemplary report! I can reproduce everything you describe (using Fx ESR 45.9.0).
You mentioned several issues, all connected to the null
problem (#619) in some way. However, wouldn't you expect RPC to allow any requests to greasemonkey-script:*
by default? That's my main question to you. I'll explain the other issues nevertheless.
The CSS resource is blocked– this is normal.
As I've said above, maybe this shouldn't be normal for most users. I think an "extension compatibility" rule should be added. Is the UUID following moz-extension:
different for each installation of the user script?
However, RP GUI displays a null blocked target.
[…]
Allowing either of those null targets has no effect on the blocking of the resource.
As you've said, this is tracked in issue #619.
When allowing requests from *.example.com to null then refreshing the page, another null blocked target appears, and this time one can only allow requests to null without a specified origin.
When allowing requests to null and refreshing the page a second time, yet another null blocked target appears, this time with no possible action.
I've seen this issue somewhere before, but since we're talking about the null
destination here, I'd classify this issue as a duplicate of #619. When #619 is fixed, all null
issues should be gone.
Is the UUID following moz-extension: different for each installation of the user script?
Yes, it is. I've just tested it. So a compatibility rule should allow all requests to the greasemonkey-script
scheme.
However, wouldn't you expect RPC to allow any requests to greasemonkey-script:* by default? That's my main question to you.
To be honest, I didn’t thought about it that much. I guess I was used to this behavior.
But you’re right, userscripts can be considered as extensions and RP should not interfere with extensions. After all, if the user has trusted the installation of a userscript, they expect any part of it to be working.
I created a gist which contains the two files:
https://gist.github.com/myrdd/63d9b593818436dffce0b0a14ee32e0c
Screenshot of the issue:
Related to #562, #447, #619 .
Browser and Add-ons
RequestPolicy settings:
Steps to reproduce
rpbug.user.js
andrpbug.css
(provided below) in one same folderObservation
The CSS resource is blocked– this is normal. However, RP GUI displays a
null
blocked target.When allowing requests from
*.example.com
tonull
then refreshing the page, anothernull
blocked target appears, and this time one can only allow requests tonull
without a specified origin.When allowing requests to null and refreshing the page a second time, yet another
null
blocked target appears, this time with no possible action.Allowing either of those
null
targets has no effect on the blocking of the resource.Expected behavior
The GUI should display the userscript resource as blocked target, and offer a way to unblock it.
Additional remarks
The request log shows an URI looking like
greasemonkey-script:5a0f2edd-46fb-44fd-b7d6-92cd584f773e/css
.One can unblock the resource by manually adding a rule with
greasemonkey-script
as destination schema and leaving all other fields blank. Alternatively, allowing all targets from*.example.com
also unblocks the resource.The file rpbug.user.js
The file rpbug.css