webRequest permission

[Offerel]

For some reason, in our network we cant use extensions with webRequest and webRequestBlocking permissions. Is it possible to have a version of this addon without this permissions by using xhr requests?

[frigus02]

Yeah, this is quite a broad permission. I understand why this may be blocked. RESTer already uses fetch under the hood. The webRequest permissions should only necessary for things that aren't possible with fetch/xhr, e.g.:

• Setting or reading special headers (e.g. Cookie, Origin, ...)
• Getting request timing data

Apparently webRequest can even be an optional permission. That might be nice. Would that work for you or would you need a version of RESTer without webRequest permission entirely?

[Offerel]

I will try to modified your current packaged version and try it. Will report later.

BTW: If i remove both permission and load the extension as unpacked extension from folder, at least POST request will fail with an error message:

TypeError: Cannot read properties of undefined (reading 'status')
    at il (chrome-extension://okkcaeaeooacijnchaldjojpgphalkgi/site/scripts/bundle.js:3740:10587)

I haven't checked this any further as of now. Will report more later...

[frigus02]

This is where the request handling logic is done: https://github.com/frigus02/RESTer/blob/master/src/site/elements/data/scripts/request.js

RESTer currently definitely relies on the webRequest permissions. But it should be possible to rewrite this so they are optional, I think.

[Offerel]

I see. I have tested the following manifest and now i can install the Extension. SO at least installing will work. But i get the same error as above, when sending the request, which is logical, when every request depends on webRequest permission. If you find the time, a version without this permission and working XHR requests would be nice.

{
"update_url": "https://clients2.google.com/service/update2/crx",

    "manifest_version": 2,
    "name": "RESTer",
    "version": "4.7.0",
    "description": "A REST client for almost any web service.",
    "author": "Jan Kühle",
    "homepage_url": "https://github.com/frigus02/RESTer",
    "icons": {
        "48": "images/icon48.png",
        "128": "images/icon128.png"
    },
    "permissions": [
        "activeTab",
        "downloads",
        "storage",
        "unlimitedStorage",
        "<all_urls>"
    ],
    "optional_permissions": [
        "cookies",
		"webRequest",
		"webRequestBlocking"
    ],
    "background": {
        "scripts": [
            "background/bundle.js"
        ]
    },
    "browser_action": {
        "default_icon": {
            "16": "images/icon16.png",
            "24": "images/icon24.png",
            "32": "images/icon32.png"
        }
    },
    "minimum_chrome_version": "67"
}

[frigus02]

I'm testing some changes in the #532. This works with optional webRequest permissions. Some tests are still failing. Looks like cookies are somehow affected.

Out of curiosity: do you know by which mechanism extensions with webRequest permission are blocked in your network? Is it through a Chrome policy (https://chromeenterprise.google/policies/#ExtensionSettings)?

[Offerel]

I'm not sure but at least Edge is restricted heavily via GPO's and I fear it's the same for Chrome. So yes, it should be a policy thing.

I know Cookies are a nightmare in WebExtensions when using xhr calls. I have the same issue and lot more with bookmark extension. Currently I didn't official support them until I find a better way.

[frigus02]

I released version 4.8.0 without webRequest permissions. I tested this locally with Chrome Policies. On sending the first request RESTer will try to request those permissions, which fails if they are blocked by policy. RESTer then logs a message to the console and proceeds with the request. The only downside is that certain headers can't set or read (e.g. Cookie).

It may take a few hours for the update to be available in the different stores.

[Offerel]

Nice. I wil try that tomorrow on an pc with this restrictions and report. Many thx so far.