Skip to content
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

Add support for Extended OTP Code Validity for Pair #520

Open
emp3r0r7 opened this issue Sep 16, 2024 · 1 comment
Open

Add support for Extended OTP Code Validity for Pair #520

emp3r0r7 opened this issue Sep 16, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@emp3r0r7
Copy link

Hello, i wanna say first of all : thank you for you huge work !!!

I have been using the webBuilder() method of the class responsible for generating OTP codes for user pairing in my application. However, I’ve noticed that the OTP code expires and refreshes approximately every 30 seconds, making it challenging for users to complete the pairing process if they take longer than this interval.

On the official web version of the platform, the OTP code remains valid for several minutes, allowing users to pair successfully even after a delay. This provides a smoother user experience, especially when network delays or user response times come into play.

Would it be possible to implement a feature that allows the OTP code to remain valid for a longer duration without automatically refreshing? This would help maintain a more consistent user experience similar to the official web version.

Thank you for considering this feature request.

Best regards,
Chris

@emp3r0r7 emp3r0r7 changed the title Feature Request: Extend OTP Code Validity for Pair Add support for Extended OTP Code Validity for Pair Sep 16, 2024
@Auties00 Auties00 added the enhancement New feature or request label Sep 20, 2024
@emp3r0r7
Copy link
Author

emp3r0r7 commented Oct 29, 2024

I finally managed myself to extend the OTP time duration by reverse engineering the original process from WA.
It is required to send an initial ping containing the id coming from the "pair-device" iq response.
After that, I noticed that it is required to start pinging constantly, but I may be wrong I added schedulePing() that starts pinging to emulate the original WA behavior.

Just edit the digestIq method into the StreamHandler class as follows , this solution works for me on Cobalt 0.0.6 :

 private void digestIq(Node node) {
        var container = node.findNode().orElse(null);
        if (container == null) {
            return;
        }

        switch (container.description()) {
            case "pair-device" -> {

                //patch BEGIN extended OTP
                var attributes = Attributes.of()
                        .put("id", node.id())
                        .put("type", "result")
                        .put("to", JidServer.WHATSAPP.toJid())
                        .toMap();

                var request = Node.of("iq", attributes);
                socketHandler.sendNode(request, null);
                schedulePing()
                //patch END extended OTP

                startPairing(node, container);
            }
            case "pair-success" -> confirmPairing(node, container);
        }
    }

Hope it helps, let me know if this works for you all.

@emp3r0r7 emp3r0r7 reopened this Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants