unable to sync - api error 'missing_method'

[kicksturns]

I can't send or receive messages all of a sudden, I get the api error 'missing_method'. Any suggestions?

[purpleidea]

I am seeing the same issue. It was working a few days ago, but I noticed this just now and came here to search.

[purpleidea]

Here is what it looks like if you screenshot right as the app loads:

My previous messages load right after and if you try to refresh you see that message again. I can't see new messages.

[michaelkourlas]

This is a VoIP.ms issue -- they may have removed one of the API methods that the app uses, or the API might be broken in some other way. I have not had a chance to investigate yet. You will need to contact them for assistance, at least in the short term.

[yulman19]

According to Eduardo from voip.ms chat, no changes were made on their end. I have a ticket open.

[divsys1]

Same issue here. Happened on an existing Samsung phone and a new install I added to my tablet for testing puposes.

Tried to open a ticket with Voip.MS, but got a reply:

"Given that this is a third party app, I suggest you contact its developer to report this issue, as this is outside the scope of our support"

[muffin-p]

I can confirm I'm having the same issue. I was texting fine this morning but getting the api error missing_method now.

[michaelkourlas]

According to Eduardo from voip.ms chat, no changes were made on their end. I have a ticket open.

That seems unlikely. The app was last updated six months ago, but this only started happening today.

I will hopefully have some time to investigate tonight or in the next few days to see if I can identify what changed and whether I can implement a fix or workaround.

[purpleidea]

voipms claims the issue is not on there end. This could be true, however many times in the past they have made this claim, sometimes it has not been the case. So it very well might be their playbook to just always say this first.

[purpleidea]

To add more info to help in debugging:

Using Android 13, Pixel phone. Using the app store version since the fdroid version doesn't have events. Ping if you need any more info.

[yulman19]

i'm on android 14, also app store version

[yulman19]

To quote from my VOIP.ms support ticket

Hello,
We have tested our API and is working correctly.
Regards.

{name}
VoIP.ms Customer Service

[The-Sleeper]

NOT working on Android 10 or 11 either...

[anaxonda]

Same error for me as of today, fdroid version, lineageos android 13.

[michaelkourlas]

As expected, this is a VoIP.ms issue.

There are two ways to make VoIP.ms API requests: GETs with query parameters, or POSTs with multipart/form-data. The app uses the latter method. It appears that all POSTs with multipart/form-data are now being rejected with the missing_method error.

EDIT: This is not correct -- see @Wyzzcow's comment below: https://github.com/michaelkourlas/voipms-sms-client/issues/262#issuecomment-1912562549

[purpleidea]

@michaelkourlas

I've relayed this information in my ticket, but I encourage everyone else to do the same so that they take it seriously. Thanks again.

[Wyzzcow]

@michaelkourlas How did you even find the rest api? On the voip.ms page, they seem to only have documentation for soap (wsdl), so how did you discover how to use https://www.voip.ms/api/v1/rest.php :)

Using the web SMS center, it does use these fields in the post data

It does use a different endpoint https://voip.ms/m/communications.post.php so who knows!

[divsys1]

Does anyone have a simple example case we can use to highlight this issue?

The best would be something using their example code/suggestions.

I don't think there's much doubt the issue is at the voip.ms end, as the client app has been stable without change for months (if not years), but the "not our app so not our problem" response is typical.

If it's easy to come up with a small code example that anyone can use of their API fail, one would hope we can get some Tickets accepted and handled promptly.

[divsys1]

@Wyzzcow : If you go to the "SOAP and REST/JSON API" section under Main Menu in the voip.ms login you'll find "Documentation and Examples (PHP and .NET)"

Their examples reference https://www.voip.ms/api/v1/rest.php directly.

[Wyzzcow]

@divsys1 Yea, saw those, but a few api calls don't really count as api documentation for the rest api. But I guess the rest api is a direct mapping to the soap api.

The examples for the REST api are pretty terrible though "https://voip.ms/api/v1/rest.php?api_username={$user}&api_password={$pass}&method={$method}&email={$email}"); as if its a good idea to send usernames and passwords directly via query params...

[divsys1]

As expected, this is a VoIP.ms issue.

There are two ways to make VoIP.ms API requests: GETs with query parameters, or POSTs with multipart/form-data. The app uses the latter method. It appears that all POSTs with multipart/form-data are now being rejected with the missing_method error.

Tried a few examples from voip.ms example code (lookup server info) and they seem to work w/POSTs. Probably the issue would be more SMS/MMS related. I noticed, if you clear account info in the app and try and reenter user/password info, you can not even login without the error.

Still would love to get a simple example to add some more pressure on the tickets from the user end.

[purpleidea]

From Voip.ms ticket:

We have contacted the department in charge, and they have confirmed that the IP is working correctly and no changes have been made to it.

[Wyzzcow]

So I think I figured out the problem. The POST to https://www.voip.ms/api/v1/rest.php set the HOST header to www.voip.ms. This causes a redirect and converts the request to GET.

Changing the URL to https://voip.ms/api/v1/rest.php fixes the issue. But unfortunately, the value is hardcoded.

[purpleidea]

If that's the case, here is a patch to fix it:

https://github.com/michaelkourlas/voipms-sms-client/pull/263

[michaelkourlas]

Thanks, @Wyzzcow -- will hopefully have time to take a closer look this evening.

[Wyzzcow]

Just looking at the postman console but if you just POST to voip.ms, no redirect

[linepoint]

Confirming what @Wyzzcow said - they changed the https://www.voip.ms URL to be a 301 redirect to just https://voip.ms/

[linepoint]

And because voip.ms has been oblivious to what they did - so I'll be snarky: I can't believe the site is claiming to be run on PHP v5.4 (ie: Jun 2013)? (At least that's what it reports in the headers when doing a curl request). ooof.

< HTTP/2 500 < date: Fri, 26 Jan 2024 21:23:35 GMT < content-type: application/soap+xml; charset=utf-8 < content-length: 276 < x-powered-by: PHP/5.4.16 < access-control-allow-origin: * < set-cookie: PHPSESSID=cjcv0mtp8cj46cneu8gjr0ko97; path=/ < expires: Thu, 19 Nov 1981 08:52:00 GMT < cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 < pragma: no-cache < x-frame-options: SAMEORIGIN < vary: User-Agent < x-ua-compatible: IE=11 < cf-cache-status: DYNAMIC < set-cookie: voipms_lang=en%7Ccp; expires=Mon, 23-Jan-2034 21:23:35 GMT; path=/; domain=.voip.ms; secure; httponly < set-cookie: __cf_bm=2owHEZNZDizLzMWvuCsA2YGlAm.zAgw7Jf.cG3rLIXg-1706304215-1-AY54taFF9infIhRC/77api7blyf9CM7EOawcTWq0QshDWL+xXnYGhbGOgYpa/EzSz0VHmiGuThAfxQ1OPffmuuA=; path=/; expires=Fri, 26-Jan-24 21:53:35 GMT; domain=.voip.ms; HttpOnly; Secure; SameSite=None < server: cloudflare < cf-ray: 84bbd160ff837117-YYZ

[michaelkourlas]

If they used a 307 instead of a 301, that might fix the problem.

[michaelkourlas]

A user pointed me to this: https://community.voip.ms/t/api-problems-cant-sign-in-with-voip-ms-sms/276/5

[UPBT]

https://perishablepress.com/stupid-htaccess-tricks/

You would think they could make a positive ID with the app's user-agent string, and then add am .htaccess rule or something as a hot-fix.

You know, just for a week or two until F-droid gets around to building the next version from source. I hope they're lurking...

[linepoint]

The redirect looks to be done in cloudflare, not on the backend server. Someone (very senior to have that access) probably made a very generic redirect rule there and forgot to tell anyone.

At least voip.ms is admitting the screw up now.

[UPBT]

A user pointed me to this: https://community.voip.ms/t/api-problems-cant-sign-in-with-voip-ms-sms/276/5

Ah.. Over there they seem to admit (contrary to prior messaging) that they did change the API...

I hope they realize how unprofessional this looks, both the unannounced API change, and the misinformation stated by their support staff (as an ironclad fact.)

It is extremely hard to troubleshoot when you are given wrong information, even more so if you can't verify it as fact yourself and they are insisting their falsehood is the truth.

It's been years, but I used to use the mod_rewrite inside of .htaccess to fix things like this

[purpleidea]

They finally admit it.

Our team made a change to redirect "www.voip.ms" to "voip.ms", however, we are using HTTP 301 status, since it's a valid way to redirect traffic the app's code should supported. Regards.

[sparksis]

Our team made a change to redirect "www.voip.ms" to "voip.ms", however, we are using HTTP 301 status, since it's a valid way to redirect traffic the app's code should supported.

Translation:

We made a security change and didn't notify you, but we expected your app to ignore OWASP recommendations and blindly trust redirects...

[michaelkourlas]

This will be fixed in the next release.

[michaelkourlas]

Someone from VoIP.ms reached out by email this afternoon, though I didn't see the email because it got caught in my spam folder. They confirmed that the issue was the 301 redirect. I suggested they try changing it to a 308, which is equivalent to a 301 but always preserves the existing method on redirect.

Regardless, an update should be coming shortly.

[michaelkourlas]

For those who don't want to wait for Google to review the update: https://github.com/michaelkourlas/voipms-sms-client/releases/tag/v0.6.26

[muffin-p]

For those who don't want to wait for Google to review the update: https://github.com/michaelkourlas/voipms-sms-client/releases/tag/v0.6.26

Thank you! Everything working fine now!

[drouleau5]

Thank you, Michael, and thanks to everyone for your comments. We have certainly taken note of them and will take appropriate action for further transparency in the future. Apologies for the headaches.

[purpleidea]

@drouleau5 It would be really awesome if your support team would stop automatically denying there's an issue whenever there's an issue. It's happened many times before today. In my support ticket for this incident the same bad pattern. Deny and close ticket. :/

[yulman19]

@drouleau5 happened to me too

[purpleidea]

@yulman19 Generally a public post-mortem is what I hope to see when companies make such mistakes. Let's see if they publish something.

[rombo121]

Here is a response I got from VoIP ms support warning me that the developer may have access to everything and to be careful. "Our API is working correctly on our end, the issue needs to be addressed on the app's end and we have no control over this app, my sincere apologies. Please contact the app developer for further details. Please note this app is developed by instances outside VoIP.ms and using it, may represent a security breach on your data, as this developer might gain access to your account and communications, please use it carefully. Thanks"

[purpleidea]

@rombo121 While I would not expect this kind of response from support, I would say you should be aware of the implications. If you use the google-play version, you add something like the following to your voip.ms account:

What this does is sends a GET request (not POST which would make much more sense voip.ms) with some data about the incoming text message. That is then relayed to your phone so you get a notification, rather than having to constantly poll. It's a very useful feature. Michael's server can see all that data. So you probably want to keep that in mind.

[muffin-p]

@purpleidea Good to know, I am glad I don't use google play services.

[balz666]

Any idea when the update should be ready on Google? It's much easier for me to download it this way rather than installing from apk.

Support from VOIP told me to use Zoiper and not use this app because they say each time they change the code it stops working.

@purpleidea : I'm not sure I get what you are saying. Are you saying that by using this app everything I write can be read by the person who wrote the app, each time I send an SMS? Is there anything that can be done to avoid this?

[purpleidea]

@balz666

I'm not sure I get what you are saying. Are you saying that by using this app everything I write can be read by the person who wrote the app, each time I send an SMS? Is there anything that can be done to avoid this?

Log in to your voip.ms account. Click on "manage DID's" -> EDIT (on the phone number you're asking about) -> Scroll down to "SMS/MMS URL Callback" as shown in my screenshot.

Paste the entire text from that box here and I will tell you.

[balz666]

I see a GET request to "https://voipmssms-notify.kourlas.com/?did={TO}"

Does it mean every SMS I text goes to there and the guy who wrote the app sees everything I write? This is crazy.

Is it the same with other apps, like Zoiper? And can the guys at VOIP see my SMS as well?

[purpleidea]

the guys at VOIP see my SMS as well

They can see every text message you send or receive. That's why you should switch to an app like signalapp which is end-to-end encrypted.

Michael's server gets data on whatever {XXX} fields you have added there. So that's your phone number. Unfortunately, since it is a GET request and not a POST, many servers who log get this information in the logs. This is an issue with how voip.ms handles callbacks, you should get them to support sending that over POST.

[balz666]

the guys at VOIP see my SMS as well

They can see every text message you send or receive. That's why you should switch to an app like signalapp which is end-to-end encrypted.

Michael's server gets data on whatever {XXX} fields you have added there. So that's your phone number. Unfortunately, since it is a GET request and not a POST, many servers who log get this information in the logs. This is an issue with how voip.ms handles callbacks, you should get them to support sending that over POST.

I'm not tech-savvy, so basically, just so I understand : can VOIP staff read my SMS and if I use another third-party app, like Zoiper, can they read my SMS?

I didn't understand what you mean with GET and POST... I just want to know if my SMS are safe with Zoiper or with VOIP.ms per se.

Thanks!