feat(captcha): add support for configurable capture type

[klords]

Description

Update: The logic is now configurable and defaults to the current implementation link but is settable per-store or with a global override in dotenv. This sidesteps the overall impact of the below discussion points (but not its relevance to the available options).

Changes the logic of the captcha handler to take a screenshot of the target element rather extracting an image url. This approach has some advantages and drawbacks worth consideration:

Pros	Cons
Prevents flagging from excessive or unusual downloads/accesses of captcha images	Counts against messaging service file upload quotas
"Future-proof" for when we want to take on harder captchas	We would have to use a strategy pattern approach anyways based on store config or other detection method
Resistant to using non-image-based captchas	Is this captcha tech in use? Would it be easier to solve anyway?

I also added the captcha handler config for all Amazon sites after testing them in bulk. It appears they all have the same structure (as one might expect). Guess that'll fix issues like #2452.

Testing

npm run test:captcha with various service configurations. Captcha test is updated to actually open a live page and grab image.

[AlexP11223]

I would make an option for the captcha capture method. Like this:

async function saveCaptchaAsync(method: string, page: Page, store: Store): CaptchaPayload {
  switch (method) {
     case 'screenshot':
       return saveCaptchaScreenshotAsync(page, store);
    case 'url' ... 
  }
}

Probably should be configurable per store, and maybe allow to override via env.

And maybe should rename DMPayload to CaptchaPayload, for adding captcha recognition services and libs (and I would extract all handlers from messaging to e.g. captcha/handler). For some captchas (such as recaptcha iirc) you may need to just extract some ID from HTML.

For saving files maybe easier to use tmp dir. https://github.com/benjamingr/tmp-promise

[klords]

That's a good thought on making the capture type configurable, will consider adding that. Any changes in anticipation of adding another processing service (e.g. paid captcha service) is premature. That refactoring can and should happen in the PR that adds that support. I have no intention of adding it. There are no captcha handlers in the messaging code. The captcha references there can simply be renamed (aside from captcha.ts, which is meant as an entry point to specific messengers for captcha messages), as they're generic convenience methods for sending a DM and awaiting response. To that end, also renaming from DM to Captcha payload is mostly not a good idea, since those DM payloads are for... DMs.

…

On Fri, Apr 30, 2021, 1:17 PM Alex Pantechovskis ***@***.***> wrote: I would make an option for the captcha capture method. Like this: async function saveCaptchaAsync(method: string, page: Page, store: Store): CaptchaPayload { switch (method) { case 'screenshot': return saveCaptchaFileAsync(page, store); case 'url' ... } } Probably should be configurable per store, and maybe allow to override via env. And maybe should rename DMPayload to CaptchaPayload, for adding captcha recognition services and libs (and I would extract all handlers from messaging to e.g. captcha/handler). For some captcha (such as recaptcha iirc) you may need to just extract some ID from HTML. For saving files maybe easier to use tmp dir. https://github.com/benjamingr/tmp-promise — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2468 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD4CIPEBU6PBY27P4DJS4LTLMF4LANCNFSM43Z2UPAQ> .

[AlexP11223]

There are no captcha handlers in the messaging code.

I mean just extracting this

streetmerchant/src/messaging/discord.ts

Line 168 in 39fac90

export async function getDiscordCaptchaInputAsync(

it seems like it can be outside of this module since it's only using the more generic exported stuff. And then all possible captcha handlers will be nicely in one place making it more clear.

I have no intention of adding it.

I can do it :)

Also I saw this lib for Amazon captchas used in fairgame, but not sure if there are JS alternatives.

Though handling Amazon captchas actually seems not very important, because there is no chance to buy a GPU manually, there are too many buying bots, and even without bots thousands of people monitor Amazon.

[jef]

Sorry @klords, I haven't gotten around to reviewing this.

Is this PR in it's final state?

[klords]

@jef no worries, similar boat here! I was able to allocate some time to this and incorporated some ideas from the feedback above. It's at a good point now, and other ideas can be vetted and/or included in a more applicable PR later on.

[jef]

Looking at this today @klords. Thanks for your patience and keeping this updated.

[jef]

Overall, looks great. I really appreciate the hard work you've put into this topic. This has been a great addition.

[jef]

👍

[jef]

suggestion(non-blocking): As previously mentioned, it could be easily to put into a temp directory. But this is fine for now as I don't want to block this.

[jef]

Changed to feat to get captured by release-please.