furaffinity ripper can now rip public albums

[cyian-1756]

Category

This change is exactly one of the following (please change [ ] to [x]) to indicate which:

• a bug fix (Fix Disabled test: BasicRippersTest#testFuraffinityAlbum -- fix and re-enable or remove #183)
• a new Ripper
• a refactoring
• a style change/fix

Description

I removed all the code for logging in (Which ripme was not able to go anymore due to a change in the login system) so the ripper can now rip all public albums.

Testing

Required verification:

• I've verified that there are no regressions in mvn test (there are no new failures or errors).
• I've verified that this change works as intended.
  • Downloads all relevant content.
  • Downloads content from multiple pages (as necessary or appropriate).
  • Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.
• I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

• I've added a unit test to cover my change.

[metaprime]

So we're removing cookie support? I think if it's unneeded it still wouldn't hurt, especially if you plan to re-add support for logging in later?

[cyian-1756]

So we're removing cookie support?

For right now at least. They added a captcha to their login page which means that ripme can't get the login cookies

I think if it's unneeded it still wouldn't hurt, especially if you plan to re-add support for logging in later?

I've been going over the site and they seem to closed off most if not all ways of automated login. The only way to let ripme access private albums that I can think of is to have the user login, export their cookies and put them into ripmes config file

[metaprime]

@cyian-1756 4pr0n/ripme#354 adds support for cookies in general (as long as each ripper adds support for that mechanism) -- even though we only have the manual process of putting the cookie value in the config file, it's better than nothing for the folks that want to configure it (and we can add a wiki page for a how-to). We can work on an appropriate UI at a later time. I feel like this missing functionality has been a blocker for long enough that it's worth considering that half-baked feature.

[cyian-1756]

We can work on an appropriate UI at a later time.

I imagine a UI for this would be pretty simple. Just throw a GUI around a JS/HTML engine and dump the login cookies to the system wide config file

4pr0n/ripme#354 adds support for cookies in general (as long as each ripper adds support for that mechanism) -- even though we only have the manual process of putting the cookie value in the config file, it's better than nothing for the folks that want to configure it

I agree. I'll get on updating and merging that PR

[metaprime]

@cyian-1756 yeah, I wanted the UI to be well-thought-out and nice to use, but it's been years we've been lacking this capability, and it's time to add it, even if it's nowhere near perfect.

[cyian-1756]

@metaprime I added the get cookies func in PR #184

[metaprime]

@cyian-1756 Merged #184

[metaprime]

Anything blocking this PR?

[metaprime]

Would this fix #183 ?

[cyian-1756]

Anything blocking this PR?

Nope.

Would this fix #183 ?

Yup

[metaprime]

I opened a new pull request #271 with this change to run this against the latest CI and re-enable the test. We can merge that one and close this one.