-
-
Notifications
You must be signed in to change notification settings - Fork 313
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
white/blacklist implemented (#44) + docs/tests updated #57
Conversation
test('http nonwhitelisted torrent does not appear in scrape', function (t) { | ||
var server = new Server({ | ||
filter: function (hash) { | ||
return hash !== parsedBitlove |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hash
is a string and parsedBitlove
is an object, so this will never be true
Good PR, but the tests need a bit of work. Don't worry about it though - I can fix them up :) |
Thanks, this is released (with some other breaking changes) as 3.0.0. |
Yep, took a look at it and things are making a lot more sense now. On a tangential note, I'm trying to figure out the best way to solve the storage adapter issue that was briefly discussed in #44. |
I believe Astro already solved issue #44 with this PR: On Fri Jan 30 2015 at 4:00:07 PM Sidd Sridharan notifications@github.com
|
Ok, I think I'm just misunderstanding some things then. I'll spend some more time tinkering, thanks! |
Cool, feel free to ask questions if anything's confusing. I think @astro intended the |
Alright, I'm unable to see how to override |
Pasting from IRC for posterity: sidd: sup |
I've added a simple filter option to the server creation parameters as per issue #44.
If
filter()
returns false, a warning is emitted and the infoHash is not added toself._torrents
. The test checks this by ensuring that the infoHash does not appear in a scrape request.