1

I'm building an extension (MV3) that will make demoing data in apps easier (ie. pumping fake data into a chart to make it more realistic than typical fake demo data).

My current approach is to take a user-inputted endpoint (ie. api.acme.com/reporting/chart) and a user-inputted override response (ie. data: [ {x:3, y:1}, {x:5, y:2} ]) and then use chrome.declarativeNetRequest.updateDynamicRules to create a redirecting rule where the redirectUrl is actually a dynamically created dataUri like so:

{
 "id": idVariable,
 "priority": 1,
 "action" : { "type" : "redirect", "redirect": {
   "url": `data:application/json;charset=utf-8;base64,${btoa(remix.response)}`
 }},
 "condition" : {
   "urlFilter": endpointVariable
 }
}

(As an aside, I'm curious if the redirect and dataUri response method is common, a generally accepted approach or if I've over-engineered.)

Most pressing, I've noticed many apps are not using query params to filter their reporting APIs but rather the body payload of a POST request. In some rare cases, I've even seen a single /reports endpoint where the body itself is responsible for defining the type of report to pull. I understand the point of DNR is to prioritize security of the user but is it possible to expose the requests' body?

Joshua
  • 99
  • 1
  • 3
  • 9
  • I'm thinking `webRequest` might be a better option for my use case... even if I could access the request payload using DNR, that would be at the time of the request (of course) which is too late to register the DNR using info from the body. webRequest on the other hand appears to allow access to the request body and as well as the ability to redirect. Still open to feedback. – Joshua Jul 06 '22 at 18:42
  • Updating my saga for anyone who follows a similar path. `webRequest` will *not* work for my use case. While it is not technically deprecated, `blocking` is on V3. I'm now at a point where I can see the body of the request using it but according to the [migration document](https://developer.chrome.com/docs/extensions/mv3/mv3-migration-checklist/), can only use `declarativeNetRequest` for blocking/redirecting. I'll need to think on how I can do that reactively using data from webRequest... doesn't appear possible at first glance. – Joshua Jul 06 '22 at 22:29
  • As much as I wanted to keep my logic within the extension for development ease, the only solution I can come up with is truly redirecting the request to a server I own where I'll be able to process the request body. – Joshua Jul 07 '22 at 00:13
  • 1
    There's no solution in ManifestV3. – wOxxOm Jul 07 '22 at 04:37

0 Answers0