1

We developing a web service. And need our important actions (i.e. money transfer) to be protected from accidental calling. In frontend we asking user to confirm such actions. Ok.

But how to prevent accidental calling in case of developer mistake?

Is it good idea, that action require some confirmation token from developer to proceed?

  • How are you envisioning someone accidentally calling a web service? – pdr Mar 12 '14 at 12:53
  • Maybe... Idea is to bring some artificial complexity to important APIs to ensure right usage. – The Architect Mar 12 '14 at 12:58
  • Is it a my delusion?) – The Architect Mar 12 '14 at 13:07
  • I'm trying to envision the problem you're trying to solve. A web service is generally written for automated systems to consume. Who do you envision being the confirmer? An automated service, who will simply confirm the challenge, every time; a user interface, which can handle confirmation itself; or an end user, who probably shouldn't be using a web service directly? – pdr Mar 12 '14 at 13:18
  • User operates on browser frontend, he send money by clicking button and confirming it in dialog box. Or in an Android App. – The Architect Mar 12 '14 at 13:32
4

A web service shouldn't force UI decisions on a consuming application (any more than it has to). Confirmation of user actions is a UI decision.

Plus, you're not really enforcing anything by forcing a confirmation step. If the consuming-application developer wishes, they can simply auto-confirm. All you're doing is making it harder to consume, either way.

If you, as an API provider, want to enforce a UI decision on an API consumer, that is fair enough. But it should be done via a combination of terms and conditions, a consumer-kill switch and a prior verification step (ie. we won't approve your production API access until we've seen the application).

  • 1
    I fully agree with this. Though with the really important actions like the money transfer in the example you should want something even stronger than confirmation, specifically an authorization. The user should confirm the action with something that provides second factor of authentication. For example one-time password you send over independent channel like SMS. – Jan Hudec Mar 12 '14 at 14:41
2

If you are exposing your web-service to 3rd party application developers, I can think of two scenarios where a critical API may be called without user consent (given your UI guidelines):

  1. A bug in the code
  2. Malicious 3rd party developer, misusing the API

Against non-sindicated usage, what I can suggest is providing your 3rd party developers with API keys, which will be needed to issue the critical API call.

This way, you can shield your application from malicious use of the API, as well as track which 3rd party made which call, to be able to track down suspicious behavior.

As for bugs in the code, they are trickier, since there is no programatic way to prevent them. A possible solution might be to have a two-phase confirmation (i.e. sending a mail to the user, with a confirmation link, which he must click for the transaction to complete), or (maybe more user-friendly, but might not be possible, depending on the service) a mail with an undo transaction link, to prevent accidental transactions after the fact.

0

If you really feel confirmation is necessary, you can make your critical services require a time-stamped token, and require the caller to obtain a token from you immediately prior to invoking the service. Have the token expire withing a couple of seconds (actual TTL should be determined after measuring latency). I agree with pdr, though, it's not a good design pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.