Downloadlinks only activated when page first loads

[JasperTack]

I am currently writing an extension that dynamically analyzes obfuscated filenames of a usenet download. It will send the filename to binsearch and the results of that search will be returned to the original web page. The results will then be injected into the original web page, so that the download links become available on that page.

This all works fine, but I would very much like SabConnect++ to catch the click events when a user clicks on the download button. When searching for an explanation for this in the code of SabConnect++, I saw that the analysis of the download url on a webpage is only done once (i.e. when the page is loaded). So any dynamically injected urls won't be analysed.

I temporarily solved this by adding support for external messages in the SabConnect++ extension. (on pages/background.js line 589 I added
chrome.extension.onExternalMessage.addListener( OnRequest );
)
and then I replicated the behaviour from the content script in SabConnect++, by sending a request message with method 'addToSABnzbd', with the download url and other necessary information. While this solution works for me, I was wondering if it won't be a better idea to make the analysis of the urls on a webpage to be triggered each time the web page is updated (after it first completed the loading). Accepting external messages on the background also resolves this, but this is maybe less safe?

[ppslim]

If I understand you correctly, the following is happening.

1. SiteA contains obfuscated filenames
2. Script running load obfuscated names and runs a search on binsearch for them
3. Returned results are injected by some means into the DOM of SiteA
4. Right now, sabconnect++ is not re-rendering the links that get injected at step 3

This sort of thing should be left for a callback, very much along the lines of what you have already done.

I would suggest submitting a pull request covering what you have done, to explore how this could be incorporate and for that matter, documented for others to do similar.

Issues #116 is already present, which is down to multiple interpretation on a site, so reprocessing the entire page is a no go.

[JasperTack]

@ppslim I added a pull request that includes my proposed changes. I was wondering if you could review this.

[ppslim]

Thanks,

I did see this, but immediately spotted this is going to take me time to analyse. Your proposal will work, but it directly exposes the internal listener to everywhere.

It certainly got me thinking at least.

External exposure needs to make sure that things are sound. This is both good, bad and very good.

Good: It gets your goal, but..
Bad: it now also exposes set_setting & get_setting to the web.
Very good: My brain kicked in and wondered if a whole new listener is needed for this, cut down to the existing one and could then well be exposed as an API for any site / project.

To put bad into context. I could to a get_settings for profile using the listener this enabled, to get the users sab server address, API, the works. I could also use set_settings to wipe things out, or even set things so I hijack the users requests (and this could start giving an attacker a users newznab API key).

There is certainly more thought needed, but I wouldn't implement yours as is.

[JasperTack]

Thanks for the feedback. I definitely do understand your concerns about security and indeed splitting the api in a private and public one would be a nice solution for this I think.
I'm curious how this will progress in the future and will keep following this repo.