Skip to content
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

feature request: support for NZBLNK links #180

Open
TobiH-GE opened this issue Dec 4, 2019 · 2 comments
Open

feature request: support for NZBLNK links #180

TobiH-GE opened this issue Dec 4, 2019 · 2 comments

Comments

@TobiH-GE
Copy link

TobiH-GE commented Dec 4, 2019

like https://nzblnk.info/nzb-monkey/

@ppslim
Copy link
Collaborator

ppslim commented Dec 4, 2019

On looking at this, there are a number of areas that indicate integration is not possible.

Chrome extensions cannot be url handlers. I believe this used to be possible in the app logic, but this has been removed.

As such, the nzblnk protocol needs to be handled by something, but the only two remaining methods are applications on the local machine registered to handle said protocol, or external web-pages, which will receive the data after nzblnk: and provide a response.

NZB Monkey in this case provides a "external application" implementation. An external site would require external resources.

The way NZBLNK works differs as well.

This extension does not perform any searches for nzbs. Instead, it reads the DOM content of each supported indexes web-page as you view a category view, or search results. When it matches the applicable patterns, it inject additional links which instead of downloading an NZB to your local machine, dispatches the URL to the download to the SAB API. The NZB download links are typically already in the results, we are just supplementing them.

However, in NZBLNK, the metadata it contains is insufficient to instruct SAB on what it needs to obtain. A new search must be conducted to a one or more indexes and the search results consulted. Provided there is a match (which there is an expectation there should be), the results will contain one or more URLs that could be sent to SAB.

NZB Monkey provides this extra layer. It handles the click of the protocol, uses the metadata from the link to conduct a search and then dispatches results to SAB if needed.

So in addition to needing to find a way to make the extension handle new protocols (which per above I don;t think is possible any more), it would also now need to start conducting searches on indexers.

I highly suspect that there are a number of problems with this that are likely to be considered suspect by the Chrome Extension review process.

Also bear in mind that this extension operates today without providing any credentials (other than to SAB). It simply acts on your visit to an indexer and leverages the fact you are logged in to view results. To conduct autonomous searches though, would require that you store credentials for the indexers.

That is not to say this would make it impossible, but I do wonder why the long route of integrating all these extra requirements, when it may have been easier to just make this extension inject one of its own links into the page you found the NZBLNK on, cutting out all this extra logistics which are effectively already complete if you can see the NZBLNK icon.

@TobiH-GE
Copy link
Author

TobiH-GE commented Dec 4, 2019

thank you for this really good answer.

nzblnk:?t=NAME&h=HEADER&p=PASSWORD

i think it could be possible that sabconnect++ can open the NZBLNK URL and search for the HEADER in your prefered NZB indexer. sabconnect++ needs a new option for this prefered NZB indexer then.

the NAME and PASSWORD can be forwarded as URL parameter and grabbed and attached to the "send to sabnzbd" button

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants