When SABnzbd fetches an NZB file through a URL on an indexer site, it can only do it on sites that do not require a login session (unless the session key is in the URL).
It would be great if SABnzbd had an option to supply a user-created session cookie file to use when fetching NZBs.
This would be especially useful for adding by URL through the API from (for example) a remote device, where it would normally need to download the NZB file itself and send it to SABnzbd.
Option to specify a session cookie for fetching NZBs by URL
Re: Option to specify a session cookie for fetching NZBs by
Each site has its own peculiar way of logging in and getting files from such a site would mean scraping.
We will not implement scraping, for technical reasons and because it may very well go against a site's policy.
SABnzbd will only work with sites that have an actual API and use authentication through API-parameters.
When talking about a "session key", I think you should be talking about an "authentication key", because the key is not session-bound.
Other than that I don't really understand your example with the remote device and the cookies.
We will not implement scraping, for technical reasons and because it may very well go against a site's policy.
SABnzbd will only work with sites that have an actual API and use authentication through API-parameters.
When talking about a "session key", I think you should be talking about an "authentication key", because the key is not session-bound.
Other than that I don't really understand your example with the remote device and the cookies.
Re: Option to specify a session cookie for fetching NZBs by
Thanks for the quick reply.
Sorry, you're correct, I should have said "authentication key".
Example: With the mobile app SABmobile, there is a feature to download an NZB through the integrated web browser and send it to the SABnzbd host through the API. The NZB can be downloaded from the indexing site because I'm logged in on the web browser. There is also the option to send only the NZB URL to SABnzbd but in this case the SABnzbd host is not "logged in" so when it attempts to fetch the NZB it fails. By using a session cookie created after login on a standard web browser I was wondering if it would be possible for SABnzbd to use this cookie when accessing that URL, like a web browser does. I think you've answered this when you wrote that SABnzbd will only use authentication through API-parameters.
Sending only the URL would use less bandwidth on a mobile device as opposed to the first method where it has to download locally and then upload the same NZB file to the SABnzbd host.
Sorry, you're correct, I should have said "authentication key".
Example: With the mobile app SABmobile, there is a feature to download an NZB through the integrated web browser and send it to the SABnzbd host through the API. The NZB can be downloaded from the indexing site because I'm logged in on the web browser. There is also the option to send only the NZB URL to SABnzbd but in this case the SABnzbd host is not "logged in" so when it attempts to fetch the NZB it fails. By using a session cookie created after login on a standard web browser I was wondering if it would be possible for SABnzbd to use this cookie when accessing that URL, like a web browser does. I think you've answered this when you wrote that SABnzbd will only use authentication through API-parameters.
Sending only the URL would use less bandwidth on a mobile device as opposed to the first method where it has to download locally and then upload the same NZB file to the SABnzbd host.
Re: Option to specify a session cookie for fetching NZBs by
I understand now, but we still want to restrict web site access to API only.
BTW: SABnzbd does support HTTP-level GZIP compression during upload, so uploading should not cost that much bandwidth.
BTW: SABnzbd does support HTTP-level GZIP compression during upload, so uploading should not cost that much bandwidth.
Re: Option to specify a session cookie for fetching NZBs by
No problem, that makes sense.
I didn't know about the HTTP-level compression, that's good to know, thanks.
I didn't know about the HTTP-level compression, that's good to know, thanks.