I'm trying to write a Chrome extension that automatically updates the search query section of the URL for search engine requests.
I would like my extension to read search engine requests using onBeforeRequest and create a new URL with my updates. That new URL should then become a dynamic rule which is followed by the browser.
However, declarativeNetRequest's updateDynamicRules doesn't update the rule fast enough to redirect the request.
How can I either speed up the dynamic rule, or slow down the request?
Related
Is it possible to get a list of all requests that were triggered by a Google Chrome but were blocked by the browser or a plugin? Something like a ERR_BLOCKED_BY_CLIENT event?
Background: I want to create an automatism (CI pipeline) that alerts if one or more elements get blocked by AdBlock or others. Sometimes their patterns match elements that are no ads and I want to know if this happens.
You can get monitor all the failed requests using the chrome.webRequest API's onErrorOccurred event and examine each one to check if the cause was ERR_BLOCKED_BY_CLIENT:
chrome.webRequest.onErrorOccurred.addListener(details =>
{
// check if it is ERR_BLOCKED_BY_CLIENT using details.statusCode or some other way
});
Just make sure you specify webRequest (along with all the hosts you need) in the permissions field in your manifest.json.
Basically I have a script on a server that runs on a MQTT/CURL signal. Once either the MQTT or CURL gets called It starts/runs the script on the server and from there transfer the data to other machines. Why I want this to be run from Chrome (or any other browser) is because I would like to use a QR scanner to scan a QR code which holds the URL(mqtt or curl) and that this then gets run from the internal browser on the device. I know that there are apps and extensions for this, but I really need to get it as "thin client" as possible due to the large amount of devices that needs to be able to send the signal. Downloading an app for each device would defeat the purpose.
So my question really is if this is possible? Can Chrome send mqtt/curl from the url/address bar. I can't seem to find any information on this (maybe because it doesn't work? :D) HTTP post wont do unfortunately.
EDIT: If it doesn't work I have an idea to curl post from the console, but then my question is how would an url that opens console and inserts certain information look like? In other words I want an URL to include in my QR picture that opens Chrome (because it's a link) opens console and writes data like 101011101 (I can do the ENTER manually)
Kind regards,
First, no Chrome can not in a single externally triggered action send a MQTT message. *
Curl is just a command line HTTP client it can send any HTTP request possible by the spec, so without LOT more detail about what exactly you are using it for the next part of this answer has to be a bit of a guess.
If you scan a QR code containing a HTTP URL then this will most likely be passed to the built in browser on the device (or a WebView in the barcode scanner application). This URL will opened using a HTTP GET request (you can not change the HTTP verb, it will always be a GET).
You can encode variables into the URLs query string by appending them to the end of the URL e.g.
http://www.example.com?foo=bar
Would send a variable named foo with a value of bar and as long as you have room in the data you store in the QR code you can add as many of these as you want.
* Chrome could be passed a URL to a page that loads the Paho Javascript MQTT library that then sends a message via MQTT over Websockets if the broker supports it, but if you are going to do that you might as well have what ever HTTP server that you load the page from send the message.
Is it possible to create a single policy that will forward all Options requests to the backend server? The only way I have figured out how to do this is by creating a new Options operation for each endpoint. That seems like a lot of unnecessary work since I want all options requests to be forwarded to the backend.
How can I create a single policy to forward all Options requests to the backend?
I don't think that is currently possible, so your only options are:
Create a separate OPTIONS operation in each endpoint.
Set up CORS (https://msdn.microsoft.com/library/azure/7689d277-8abe-472a-a78c-e6d4bd43455d#CORS) policy on a product or global level, so that OPTIONS requests would be served by APIM and not forwarded to backend at all.
Actually it is, operation template support wildcard /*
I am trying this, but since our API requires an SubscriptionKey, it is still not working. Since ApiMgmt will return 401 for options request, since browsers dont send the SubscriptionKey header.
Would be nice with the possibility to open single operations...
https://feedback.azure.com/forums/248703-api-management/suggestions/19450117-feature-to-ignore-api-management-subscription-key
I have a website where you can request data using ajax from our servers as json (only to be used on our site). Now i found that people start using our requests to get data from our system. Is there a way to block users from using our public json API. Ideas that i have been thinking about is:
Some kind of checksum.
A session unique javascript value on the page that have to match server-side
Some kind of rolling password with 1000 different valid values.
All these are not 100% safe but makes it harder to use our data. Any other ideas or solutions would be great.
(The requests that you can do is lookup and translations of zip codes, phone numbers, ssn and so on)
You could use the same API-key authentication method Google uses to limit access to its APIs.
Make it compulsory for every user to have a valid API key, to request data.
Generate API key and store it in your database, when a user requests one.
Link: Relevant Question
This way, you can monitor usage of your API, and impose usage limits on it.
As #c69 pointed out, you could also bind the API keys you generate to the API-user's domain . You can then check the Referer URL ($_SERVER['HTTP_REFERER'] in PHP), and reject request, if it is not being made from the API-user's domain.
I want to set up a project page on GitHub, so that it acts as a live site.
The site would require an API sid & token (both just long strings of text) that, in a self-hosted environment, the user would just add to the config file.
If I host this through GitHub project pages, users will supply their sid/token through a form. The page with the form will need to be served over SSL so that the sid/token aren't transferred as cleartext. The problem is that GitHub project pages don't allow SSL.
So, if I can find another secure way to take input through a form aside from using SSL, then I can host this whole thing a hosted service through GitHub project pages.
The project would be open source, so I don't expect any sort of encoding/hashing scheme to work, since the methods would be public.
The sid/token are being used in curl calls to an API which is sent over SSL. Perhaps there's a way to direct the form input directly to that SSL URL instead of having it go through the non-SSL GitHub project page...
Any ideas?
You can just give the action attribute of the form the HTTPS URL of the target script, if that's possible.
You could also use some kind of Challenge-Response encryption/hashing scheme using Javascript. The algorithm for that would be something like this:
Server generates unique, random token, saves it and sends it to the client along with the form HTML.
On the client side, Javascript intercepts the form submission and hashes the sensitive form data with the server-generated token as a salt.
Server can now check whether the hash is equal to its own calculated hash value
HOWEVER
A man-in-the-middle attacker with the ability to modify traffic (for example through ARP poisening, DHCP or DNS spoofing) could always strip all your client-side protection mechanisms from the served HTML. Have a look at SSLStrip for a tool to rewrite HTTPS URLs to unsecure HTTP URLs on the fly. The challenge-response could be defeated something like this:
Save token sent by the server, remove the Javascript from the HTML form.
As the form submission is not intercepted now, we get the raw input data.
Hash the data using the same algorithm that the Javascript would have performed.
Thank you for all the fish.
You see, an intercepting attacker can probably defeat any defense mechanism you try to make up.