Skip to content

#4 add mobile_send() and mobile_token() for SMS registration and login - #69

Open
bibonix wants to merge 1 commit into
zold-io:masterfrom
bibonix:4-mobile-api
Open

#4 add mobile_send() and mobile_token() for SMS registration and login#69
bibonix wants to merge 1 commit into
zold-io:masterfrom
bibonix:4-mobile-api

Conversation

@bibonix

@bibonix bibonix commented Jun 19, 2026

Copy link
Copy Markdown

Issue #4 asks for a mobile API so SDK callers can register and log into WTS without driving the website. The WTS server exposes the corresponding endpoints at GET /mobile/send and GET /mobile/token in zold-io/wts.zold.io under front/front_login.rb: the first delivers a four-digit confirmation SMS to an E.164 phone number, the second exchanges that code for the <login>-<token> string the rest of the SDK expects in Zold::WTS.new(key). Neither endpoint requires the X-Zold-WTS header, so they cannot be reached through an instance that already needs a key.

This change adds two class methods on Zold::WTS mirroring those endpoints: mobile_send(phone) issues the registration request with noredirect=true and returns the short status text the server sends back, while mobile_token(phone, code) posts the confirmation and returns the ready-to-use API token. Both run the response through the same X-Zold-Error and status-code checks the instance methods apply via clean. The matching Zold::WTS::Fake.mobile_send and Zold::WTS::Fake.mobile_token keep the in-memory gateway usable in downstream tests. Four new minitest cases stub the endpoints with webmock and exercise both the real and the fake implementations offline.

Locally on Ruby 3.3 with the project Gemfile: bundle exec rake test runs 12 tests with 14 assertions, 0 failures, 0 errors, and 91.51% line coverage. bundle exec rubocop lib/zold/wts.rb test/zold/test_wts.rb reports the same 16 offences master carries on the same files, none of them introduced by this diff. The rake workflow stays red on this branch because the rubocop step crashes inside rubocop-rspec_rails inject_defaults!, which is the pre-existing failure tracked in #68 and reproduces on every master commit since 7c79029.

Closes #4

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mobile API

1 participant