Develop Reference

Intercept and replace images in web app with Chrome extension

I am attempting to write a chrome extension (for personal use) to swap/replace images loaded by a webpage with alternate images. I'd had this working for some time using chrome.webRequest, but am attempting to bring it up-to-speed with manifest v3.
My general solution is that I am hosting my replacement images on my own server, including a script to retrieve as json a list of such images. I fetch that list and, for each image, create a dynamic redirect rule with chrome.declarativeNetRequest.updateDynamicRules.
This all works beautifully if I request an image to be replaced in a main frame. I can see the successful match with an onRuleMatchedDebug listener, and (of course) the path is dutifully redirected.
However, when I load the web app that in turn loads the image (with javascript, presumably with xmlhttprequest?), the redirect rule does not trigger. The initiator (a javascript source file) is on the same domain and similar path to the images being replaced.
//manifest.json
{
"name": "Image replace",
"description": "Replace images in web app",
"version": "2.0",
"manifest_version": 3,
"background": {"service_worker": "background.js"},
"permissions": [
"declarativeNetRequestWithHostAccess",
// "declarativeNetRequestFeedback" // Not necessary once tested
],
"host_permissions" : [
// "https://domain1.com/outerframe/*", // Not necessary
"https://domain2.com/innerframe/*",
"https://domain3.com/*",
"https://myexample.com/*"
]
}
// background.js
//chrome.declarativeNetRequest.onRuleMatchedDebug.addListener((info) => console.log(info)); // Not necessary once tested
var rules = [];
var idx = 1;
fetch("https://myexample.com/list") // returns json list like: ["subdir1\/image1.png", "subdir1\/image2.png", "subdir2\/image1.png"]
.then((response) => response.json())
.then((data) => {
console.log(data);
for (const path of data) {
var src = "https://domain2.com/innerframe/v*/files/" + path; // wildcards a version number
var dst = "https://myexample.com/files/" + path;
rules.push({
"id" : idx++,
"action" : {
"type": "redirect",
"redirect": {
"url": dst
}
},
"condition" : {
"urlFilter": src,
// In the end I only needed main_frame, image, and not xmlhttprequest
"resourceTypes": ["main_frame", "image"]
}
});
}
chrome.declarativeNetRequest.updateDynamicRules({"addRules": rules, "removeRuleIds" : rules.map(r => r.id)});
});
Again, this DOES all work IF I load a source image directly in chrome, but fails when it's being loaded by the javascript app.
I also attempted to test the match by specifying the proper initiator with testMatchOutcome, but my browser seems to claim this API does not exist. Not at all sure what could be wrong here.
// snippet attempted after above updateDynamicRules call
chrome.declarativeNetRequest.testMatchOutcome({
"initiator": "https://domain2.com/innerframe/files/script.js",
"type": "xmlhttprequest",
"url": "https://domain2.com/innerframe/v001/files/subdir/image1.png"
}, (outcome) => console.log(outcome));
I would expect a redirect to "https://myexample.com/files/subdir/image1.png"
Instead, I get this error:
Uncaught (in promise) TypeError: chrome.declarativeNetRequest.testMatchOutcome is not a function
Documentation https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#method-testMatchOutcome says it's supported in chrome 103+. I'm running chrome 108.0.5359.72
Thanks!
Edit: Example code updated to reflect my answer below.

I've managed to work out why direct requests were redirected while script loaded ones were not. My problem was with the initiator and host permissions. I had been relying on Chrome developer tools to provide the initiator, which in the above example originated with domain2.com. However, the actual host permission I needed was from a third domain (call it domain3.com), which seems to be the source of the content that loaded scripts from domain2.com.
I discovered this when I recalled that host permissions allows "<all_urls>", which is not a good idea long term, but it did allow the redirects to complete. From there, my onRuleMatchedDebug listener could fire and log to the console the characteristics of the redirect, which showed me the proper initiator I was missing.
Having a concise view of the redirects I need, I can now truncate some of these options to only the ones actually needed (edited in original question).
Subsequent to that I thought to look back at the HTTP requests in developer tools and inspect the Referer header, which also had what I was needing.
So, silly oversights aside, I would like to leave this question open a little while longer in case anyone has any idea why chrome.declarativeNetRequest.testMatchOutcome seems unavailable in Chrome 108.0.5359.72 but is documented for 103+. I'd chalk it up to the documentation just being wrong, but it seems this function must have shipped at some point and somehow was erroneously removed? Barring any insights, I might just submit it as a bug.

Resource not found when attempting to send voice message through AWS Pinpoint

I currently have a Node.js service to send a voice call through AWS Pinpoint. However, I'm getting a Resource not found response after making a call. I tested with PinpointSMSVoice.sendVoiceMessage which succeeds in making the call. The one that doesn't work is Pinpoint.sendMessages. My request object looks like this:
{
ApplicationId: 'project-id',
MessageRequest: {
Addresses: {
['destination-number']: {
ChannelType: 'VOICE',
Substitutions: {
// Using a template
}
}
},
MessageConfiguration: {
VoiceMessage: {
LanguageCode: 'en-US',
OriginationNumber: 'origination-number'
}
},
TemplateConfiguration: {
VoiceTemplate: {
Name: 'voice-template
}
}
}
};
pinpoint.sendMessages(requestObj, callback);
I should note that I am not in sandbox mode, it was approved and moved to production mode. I have tested the same setup with SMS which works perfectly well. I'm not quite sure what the difference is between PinpointSMSVoice.sendVoiceMessage and Pinpoint.sendMessages, except for the fact that Pinpoint.sendMessages allows me to set a template. Any ideas on what else I could be missing?

I'm encountering the same issue. It works using PinPointSMSVoice client, but that won't let me use a template. I've also tested this using V3 of the AWS JS SDK, which modularizes the clients #aws-sdk/client-pinpoint-sms-voice and #aws-sdk/client-pinpoint, but the behaviour is the same. It works uses the same tempplate in the 'Test Message' feature in the console, so seems to be a JS SDK issue. I suggest you raise the issue with JS SDK team https://github.com/aws/aws-sdk-js-v3

When you use PinPoint to perform the sendVoiceMessage operation, you need to set the content type to application/json. If you do not, you get this exception. To see an example (this is the AWS Java API), see this Github URL:
https://github.com/awsdocs/aws-doc-sdk-examples/blob/master/javav2/example_code/pinpoint/src/main/java/com/example/pinpoint/SendVoiceMessage.java

How to use FIDO credentials with WebAuthn on mobile

I have implemented desktop browser based U2F using the firefox-built-in and chrome-with-javascript U2F API. I've followed the basic recipe here:
https://github.com/castle/ruby-u2f
For each physical device, I have 4 attributes:
certificate
key_handle
public_key
counter
I believe, but I am not certain, that having harvested this information about this physical device, I can now repurpose it when rendering the exact same web page on a mobile device to implement WebAuthn, which, instead of rendering a web page for the user to authenticate, will render a mobile-os-native interface to request NFC authentication (if the device has NFC).
I am trying to use the 4 attributes above to render javascript with nav.credentials.get, but I am stuck.
It's not clear to me which of the following is true
A) You CAN use the credentials / information collected and validated during the U2F device registration process on desktop web for authentication on mobile with web authn
B) If you wish to you use web authn on mobile so it can trigger a native mobile NFC authentication process, you must, in addition to the regular U2F flow, also secretly process webauthn registration (by "secret" i don't mean you're intentionally not telling the user that they're doing this, but rather, the user is unaware of the distinction between A and B).
Following the example linked above, their javascript is something like:
var appId = <%= #app_id.to_json.html_safe %>
var registerRequests = <%= #registration_requests.to_json.html_safe %>;
var signRequests = <%= #sign_requests.as_json.to_json.html_safe %>;
u2f.register(appId, registerRequests, signRequests, function(registerResponse) {
var form, reg;
if (registerResponse.errorCode) {
return alert("Registration error: " + registerResponse.errorCode);
}
form = document.forms[0];
response = document.querySelector('[name=response]');
response.value = JSON.stringify(registerResponse);
form.submit();
});
Using the mozilla example here:
https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredentialRequestOptions
I am attempting to adapt that into something like:
var appId = <%= #app_id.to_json.html_safe %>
var registerRequests = <%= #registration_requests.to_json.html_safe %>;
var signRequests = <%= #sign_requests.as_json.to_json.html_safe %>;
var options = {
challenge: new Uint8Array([/* bytes sent from the server */]),
rpId: "example.com" /* will only work if the current domain
is something like foo.example.com */
userVerification: "preferred",
timeout: 60000, // Wait for a minute
allowCredentials: [
{
transports: "usb",
type: "public-key",
id: new Uint8Array(26) // actually provided by the server
},
{
transports: "internal",
type: "public-key",
id: new Uint8Array(26) // actually provided by the server
}
],
extensions: {
uvm: true, // RP wants to know how the user was verified
loc: false,
txAuthSimple: "Could you please verify yourself?"
}
};
navigator.credentials.get({ "publicKey": options })
.then(function (credentialInfoAssertion) {
// send assertion response back to the server
// to proceed with the control of the credential
// update the hidden form input then
form.submit();
}).catch(function (err) {
console.error(err);
});
But it's not clear how I map the U2F attributes to the webauthn attributes. I can't seem to find a concrete example of this working, but I am certain it does work because GitHub and DropBox both have this exact flow - you register the U2F device on desktop web, and then the NFC device is usable on native mobile.
The reason, by the way, that I want to implement this is that the user, on native mobile, never has to leave your web app, the native NFC interface is rendered and they are magically taken back to your web app. What I currently have is, if mobile is detected, render the OTP interface, which requires the user to switch over to an authenticator app like Authy, and then copy the OTP and go back to mobile web. It's much nicer to just pull our your key and buzz it.
Thanks for any help,
Kevin

When using the navigator.credentials.get(), make sure to set the extensions: {appid: u2f_appid}, i.e. the U2F appId parameter during u2f.register call. In my case I used the origins.json trustedfacet list URL.
https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredentialRequestOptions/extensions
The reason you need to set extensions.appid parameter is if WebAuthn rpId fails, it will fallback to older U2F using the extensions.appid parameter

Adobe DPS Android Entitlement

We are stuck with an Adobe DPS project. We cant get our DPS android app to do Entitlement for our print subscribers and we were wondering if anyone out there has managed to get this right.
We've used Adobe's tutorial here:
http://www.adobe.com/devnet/digitalpublishingsuite/articles/library-store-combined-template.html, with isEntitlementViewer set to true.
The code asks for a username and password and then via Adobe's API AdobeLibraryAPI.js, it authenticates a user via our own API. the very same code is working 100% in the iPad version of the app.
The file that actually processes the login (called LoginDialog.js) contains the following code within a function called clickHandler (we’ve added a few javascript alerts to try debug the login process)
// Login using the authenticationService.
var transaction = adobeDPS.authenticationService.login($username.val(), $password.val());
alert("1: "+transaction.state ); //returns “1: 0”
transaction.completedSignal.addOnce(function(transaction) {
alert("2: "+transaction.state ); //never returns
var transactionStates = adobeDPS.transactionManager.transactionStates;
if (transaction.state == transactionStates.FAILED) {
$("#login .error").html("Authentication Failed.")
} else if (transaction.state == transactionStates.FINISHED){
this.$el.trigger("loginSuccess");
this.close();
}
alert("3: "+transaction.state ); //never returns
}, this);
alert("4: "+transaction.error ); //never returns
Anyone out there with some DPS/android/Entitlement experience?

Android Entitlement only works after an integrator ID is registered with Adobe, as the android viewers service routes are only configured via the integrator ID.
If you do not have an integrator ID, you need to acquire one from Adobe Support.
Also it is worth mentioning, that in contrary to iOS, Android DPS viewers only support one base Route/URL for Authentication and Entitlements.
For Example whereas in iOS you can have the login been done via the first URL:
https://example.com/api/v1/SignInWithCredentials
The second URL for entitlements can be on a different URL:
http://server2.example.com/v1/api/entitlements
In android both URLs have to be the same, e.g.:
https://example.com/api/v1/SignInWithCredentials and
https://example.com/api/v1/entitlements

"chrome.permissions is not available" when requesting optional permissions for my extension

I am building an extension that requires access to history to provide one of the features.
After publishing a version which contained the permission as mandatory and consequently losing a part of my users because they got scared away by the big alert saying that the extension might be able to snoop into their history (I really didn't plan on doing that), I decided to publish a version with the offending part removed and the permission disabled as a temporary fix.
I'd like to implement this feature back using optional permissions.
First of all, I added the new optional permission to my manifest file:
...
"permissions": [
"https://news.ycombinator.com/",
"http://news.ycombinator.com/"
],
"optional_permissions": [ "history" ],
...
Then, I built a function to request permissions into the script which handles the extension's settings:
Settings.prototype.applyPermissions = function (permissions, map) {
Object.keys(permissions).forEach(function (key) {
if (map[key]) {
var checkbox = map[key].getElementsByTagName("input")[0];
checkbox.addEventListener("change", function (e) {
if (this.checked) {
chrome.permissions.request(permissions[key], function(granted) {
if (granted) {
// Permission has been granted
} else {
// Not granted
}
});
}
});
}
});
};
The key part here is this:
checkbox.addEventListener("change", function (e) {
if (this.checked) {
chrome.permissions.request(permissions[key], function(granted) {
if (granted) {
// Permission has been granted
} else {
// Not granted
}
});
}
});
I perform the request on an event caused by user interaction (the guide states that it won't work otherwise), and pass permissions[key], an object specified in my extension's settings which looks like this:
"permissions": {
"mark_as_read": {
"permissions": ["history"]
}
}
When accessing it as permissions[key], I get this part:
{
"permissions": ["history"]
}
Which is basically the format that the documentation shows for this kind of requests.
If I run this code and toggle the checkbox that should enable the feature, and look at the error log, I see this error:
chrome.permissions is not available: You do not have permission to
access this API. Ensure that the required permission or manifest
property is included in your manifest.json.
I also tried accessing this API from a background page, where it was actually available but I was not allowed to use because Chrome requires that you access it from a user interaction, and such interaction is lost if you send a message to the background page from your content script to request activation.
Am I missing something obvious here? Maybe I need to add something to the manifest, but I can't find any explicit documentation about it.

I assume you're trying to do this from a content script. You can't access most chrome.* APIs from content scripts, including chrome.permissions. However, you've correctly pointed out that a background page is also unsuitable, because you a permission change requires a direct user action.
Luckily, we have hardly exhausted our options. You could set the permission in:
The extension's options page
A browser action popup
A page action popup
Any page in your extension served through the chrome-extension:// scheme, provided you include the page and necessary sub-resources as web_accessible_resources in your manifest
In the last case, get the URL using chrome.extension.getURL. You could possibly use an iframe to inject it directly into the page, if you don't want the permission-requesting interface to be separate from the current page.
So, in fact, content scripts and background pages are the only two extension contexts where you can't use chrome.permissions.