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 a JMPVerifyProvider (using the JMP REST API) #77

Closed
ossguy opened this issue Apr 14, 2017 · 5 comments
Closed

Add a JMPVerifyProvider (using the JMP REST API) #77

ossguy opened this issue Apr 14, 2017 · 5 comments
Assignees
Milestone

Comments

@ossguy
Copy link

ossguy commented Apr 14, 2017

Per kontalk/androidclient#989 (comment) , the existing methods which verify that a number can receive messages are a bit too expensive (and thus the less-good method of "missed call verification" (or "CLI") is used instead). Per kontalk/androidclient#989 (comment) , the https://jmp.chat/ project is willing to let Kontalk use its verification tools gratis, but this requires integration to JMP's API.

This ticket will initially track the progress of the JMP REST API itself, as it is not yet ready for use. Once it's ready, then the JMPVerifyProvider can be built, using code similar to https://github.com/kontalk/tigase-extension/blob/master/src/main/java/org/kontalk/xmppserver/registration/NexmoVerifyProvider.java - just using a REST API instead of the Nexmo SDK. Per the discussion in the [email protected] MUC today, the JMP REST API will implement endpoints similar to the Verify Request and Verify Check endpoints described at https://docs.nexmo.com/verify/api-reference/api-reference .

@daniele-athome indicated that it would be good to resolve #46 around the same time, so the completion of this ticket may depend on that as well.

@ossguy
Copy link
Author

ossguy commented Apr 22, 2017

@daniele-athome I've implemented the JMP REST API, which is currently beta-quality. It's available at https://jvr.api.jmp.chat/verify and https://jvr.api.jmp.chat/verify/check (similar paths to the Nexmo API).

It currently implements the Verify Request and Verify Check parts of https://docs.nexmo.com/verify/api-reference/api-reference - right now only the Required parameters are supported. Also, the only response output format is JSON; just use /verify directly (instead of /verify/json).

Please let me know if you have any questions as you test it (and please reach out to me to get your credentials). Right now if you hit /verify multiple times with the same parameters, it will send SMS on the first two hits, then place calls on the second two, then reject further calls within 10 minutes of the first hit. I'm happy to change any of those parameters if you like.

If you want to review the source code for the JMP REST API server, it's available (should closely track what I'm actually running in production):

https://gitlab.com/ossguy/jmp-verifier

daniele-athome added a commit that referenced this issue Apr 25, 2017
@daniele-athome daniele-athome self-assigned this Apr 26, 2017
daniele-athome added a commit that referenced this issue May 3, 2017
@ossguy
Copy link
Author

ossguy commented Jun 16, 2017

@daniele-athome I just finished updating the JMP REST API to use the auto-retry logic we discussed. So one no longer needs to hit /verify multiple times - the verifier will automatically advance to the next stage at the configured timeouts. In particular, it will send an SMS immediately upon /verify, and then place the first call 120 seconds later, and then the second (and last) call 90 seconds after that, assuming in each case that the number has not yet been verified. After 300 seconds from the initial /verify hit, the code will disappear/expire and the user can try again if needed.

I haven't yet implemented any of the Verify Control or optional parameters on https://docs.nexmo.com/verify/api-reference/api-reference yet so it's not possible, for example, to set a next_event_wait at /verify call time, or to cancel or trigger_next_event via /verify/control - the verification will always proceed through all of the steps until all calls have been made or the user has entered the correct verification code.

It's easy for me to change the timeout settings in my config file if any of the above values seems non-ideal to you (especially in light of them not being dynamically-configurable). Just let me know.

@daniele-athome
Copy link
Member

Just perfect, thank you. I'll setup the test istance today to make some tests. I'll also publish an announcement on the forum for people who want to get on board with the tests (you're welcome to participate too of course if you want :-))

@daniele-athome
Copy link
Member

Server-side part is completed and the app is working perfectly. Beta test has begun, I'll post a topic in the forum later tonight (after having adjusted a few small things in the app) to announce it. Thanks @ossguy!!!

@daniele-athome
Copy link
Member

daniele-athome commented Jun 27, 2017

In the meantime that tests are under way, please consider taking my client code as a donation to your project (take the whole package and rename it, change stuff, whatever):
https://github.com/kontalk/tigase-extension/tree/master/src/main/java/org/kontalk/xmppserver/registration/jmp

Feel free to build a library out of that (as a matter of fact, I'll be using it if you do :D). It's a complete client, the only thing it's missing is connection and read timeout settings which should be set via retrofit methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants