search

KartikTalwar / gmail.js

Gmail JavaScript API
MIT License
3.74k stars 455 forks source link

Conflicting warning when using new-style ID in email_source_async #677

Closed controldev closed 2 years ago

controldev commented 2 years ago

Version: 1.0.18 (npm)

The README states the following:

gmail.get.email_source_async(identifier=undefined, callback, error_callback, preferBinary=false)

Retrieves raw MIME message source from the gmail server for the specified email identifier.

identifier must be an object or string which uniquely identifies an email:

However, when provided with a new-style ID, the method throws a warning:

gmail.js:3199 GmailJS: Warning! Using new-style ID in method expecting legacy-style IDs! Attempting to resolve via cache, but there's no guarantee this will work!,

even though the README states the opposite.

josteink commented 2 years ago

You're right. This seems to be an error in the documentation.

Looking into this issue though, I observed something interesting. Basically the URL we've used to trigger download is akin to this:

https://mail.google.com/mail/?view=att&th=**LEGACY-ID**&attid=0&disp=comp&safe=1&zw

Trying to manually downloaded an email though, it seems like the final URL the browser is redirected to before we get the MIME-stream contains the new-style ID instead:

https://mail-attachment.googleusercontent.com/attachment/?....&view=att&permmsgid=**NEW-STYLE-ID**&disp=comp&safe=1&...

The URL retains many of the same aspects and parameters, but it uses a different key for new-style IDs (permmsgid instead of th). Based on that I tried the folllowing:

https://mail.google.com/mail/?view=att&permmsgid=**NEW-STYLE-ID**&attid=0&disp=comp&safe=1&zw

And that actually works! :champagne: That means we don't even have to rely on legacy IDs to download emails, which is great.

As such, I think improving the implementation is a better fix than simply updating the documentation, but I can't promise I will have time to do it right away.

PRs welcome? :)

josteink commented 2 years ago

This should now be fixed in v1.0.21.

The function should now accept both kind of parameters, without generating warning, and using the optimal url-format for the different identifier types.