This PR intends to bring a change in the way the extension hooks into the running Hoppscotch page.
Implementation
With the new hooking mechanism, the extension doesn't rely upon the content script being executed in the page based on the manifest. Instead, it features a lot more hands-on approach. It will listen for tab updates throughout the browser and try to inject the data into content script file into the tabs which have their origins included in a origin list. The origin list is defined by the user and contains the origins which the extension (with the new hooking mechanism) should hook onto. The user can access and update the origin list by clicking on the extension button on their browser bars.
Why ?
The main motivation to this implementation over the current one is to allow users to include their own origins. With the present approach, the origins are fixed in the manifest. Many people run self-hosted versions of Hoppscotch or run Hoppscotch within containers and this allows those folks to still take advantage of the extension without resorting to building the extension with their origins included on the manifest.
Side-effects ?
Well, the current implementation overrides a ton of the safeguards that the browser manifest based hooking provides. Browsers are forced to assume a bit more general and low security permissions to the extension. This may increase review times for all further releases of the extension (especially on Chrome Web Store) as they would have to perform a more rigorous testing regimen on the extension. Also, the user facing permission screen will read out a bit more 'evil' seeming on the respective browser install prompts as well.
Progress
[x] Initial (PoC) implementation
[x] Implement proper CRUD operations on the origin list
[x] URL validation (make it so invalid origins are not accepted and origins are cleanly added (remove trailing slashes (if any) etc))
This PR intends to bring a change in the way the extension hooks into the running Hoppscotch page.
Implementation
With the new hooking mechanism, the extension doesn't rely upon the content script being executed in the page based on the manifest. Instead, it features a lot more hands-on approach. It will listen for tab updates throughout the browser and try to inject the data into content script file into the tabs which have their origins included in a origin list. The origin list is defined by the user and contains the origins which the extension (with the new hooking mechanism) should hook onto. The user can access and update the origin list by clicking on the extension button on their browser bars.
Why ?
The main motivation to this implementation over the current one is to allow users to include their own origins. With the present approach, the origins are fixed in the manifest. Many people run self-hosted versions of Hoppscotch or run Hoppscotch within containers and this allows those folks to still take advantage of the extension without resorting to building the extension with their origins included on the manifest.
Side-effects ?
Well, the current implementation overrides a ton of the safeguards that the browser manifest based hooking provides. Browsers are forced to assume a bit more general and low security permissions to the extension. This may increase review times for all further releases of the extension (especially on Chrome Web Store) as they would have to perform a more rigorous testing regimen on the extension. Also, the user facing permission screen will read out a bit more 'evil' seeming on the respective browser install prompts as well.
Progress
Happy Hacking!