-
-
Notifications
You must be signed in to change notification settings - Fork 820
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add setting to spoof URLs in network requests #1486
Comments
web: Fix cors issues with http (close ruffle-rs#1486)
Re-opening because it would still be useful to allow more advanced URL spoofing, although it's not as pressing with |
I'm also interested in this. Just saying, that as a temporary solution until this is properly implemented, you can simply hijack the fetch calls: (function (originalFetch) {
const changeUrl = function (url) {
//TODO: Check url parameter and modify as needed
return url;
};
window.fetch = function () {
let a = Array.from(arguments);
if (typeof(a[0]) === "string") {
//Argument to fetch() call is a raw URL string
a[0] = changeUrl(a[0]);
} else if (a[0] && typeof(a[0].url) === "string") {
//Argument to fetch() call is a request object
//HACK: This replaces the entire request object with an URL
// because the Request.url property is readonly.
// This is appropriate for GET requests only.
const changedUrl = changeUrl(a[0].url);
if (changedUrl !== a[0].url) {
a[0] = changedUrl;
}
}
return originalFetch.apply(window, a);
};
})(window.fetch); This code is good enough to rewrite simple GET requests which is usually sufficient to redirect requests that pull resources at runtime. For true interception you would need to reproduce the request object, but I'm not sure if you can reliably do that for POST requests with body data. |
Looks cool! Please tell me more: where and how exactly should I implement this code? |
Peferrably hardcoded in a script tag that appears very early in the page, or at least before ruffle is loaded. |
Add a setting to pattern match and replace URLs in network requests. By default we currently auto-upgrade HTTP to HTTPS, but a more general URL-rewrite mechanism would be useful.
This could be used as a workaround for issues with CORS, allowing files to be loaded from a different location than was originally coded into the SWF, and allow for redirecting dead services to a new reimplementation (Mochi high scores, etc.).
The text was updated successfully, but these errors were encountered: