Page MenuHomePhabricator

Standalone Bash script for testing authenticated API endpoints
Closed, InvalidPublic

Description

tl;dr: create a generic Bash script to test API endpoints, using Aaron Schulz's script as a starting point.

Details:

While many of our APIs have convenient sandboxes, not all do. And even for those that do, it is sometimes convenient during development and testing to hit the endpoint directly, so that the request can be fully customized. This is particularly helpful when generating malformed requests to exercise error behavior.

For endpoints that allow anonymous access, this can be conveniently done in several ways (browser, curl, Postman, etc.). But for endpoints that require authentication, especially when confirming csrf token behavior, this is much less convenient. Obtaining the necessary tokens through the Action API endpoints requires several steps, and is daunting to people unfamiliar with the process.

@aaron wrote a great little Bash script for invoking API endpoints from the command line. It performs all the token handling, requiring only that the user do a bit of copy/paste and enter their password, then invokes and Action API endpoint and a REST API endpoint.

@BPirkle customized this to call the under-development Reading Lists endpoints, and to echo the full curl commands. The idea is that you run the script once, then copy the curl commands and manually execute them. This allows convenient testing of the endpoints during development by using your command history.

Here is a video of me demoing the script, just to make sure all of that is clear.

While this is useful as-is, it is very specific to the current endpoints being developed.

We should consider how to extend this script to make it more generic and generally useful. For example, we might allow it to read the list of endpoints to be executed from a separate file. And/or generate a Postman collection, allowing the commands to be executed from Postman rather than the command line for people who prefer that. (Here's code that generates a Postman collection from a swagger spec. While that's not what we want here, it might be possible to steal ideas from it.) Or whatever else we can think of.

Steps to be completed for this task:

Edit: this need not remain a Bash script. It could be converted to another language (such as a standalone PHP script) if that seems better.

Event Timeline

Using the suggestions from Bill in the task, I considered an extension of the script from the structure of extension development of rest endpoints;

  1. Using the reading list file structure, the goal was to implement the script such that it reads from a file(usually, extension.json or any json file indicated, the rest routes that are listed)

The assumption was that for any services, the routes will be defined in a particular file, using the same format, hence, we can access that file, get the route and also the method to make the call.

  1. I I thought to keep it a bash script also because I was thinking of it's possible use case outside php services since we have other services that may not be php.

@codebug why on your personal github and not in gerrit or gitlab?

@FJoseph-WMF the last checkbox had said my personal github was fine to start with, that's why. should I move it?

My bad. I didn't read the description. Go with what the ticket says.

@codebug , I see you've made progress on this.

Here is the current version of Aaron's original script, as I have modified it for testing Reading Lists:
https://gist.github.com/bpirkle/add6448c1a9dd6795cfb2ed09ef9139c

How would I split out the reading-list-specific calls into a separate file using what you've done? Can you post (anywhere that's convenient) a working example that I could use? To try it out yourself on your own local MediaWiki dev environment before posting, you'll want this work-in-progress patch with the latest Reading Lists changes:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ReadingLists/+/988736

If you don't pull that patch into your local, you won't have the new endpoints and the script will fail. I'd suggest:

  1. pull the patch with the new endpoints
  2. run the script from my github to confirm it executes happily (just make sure there are no 404s, exceptions thrown or any other major failures)
  3. move my calls into a separate file that executes via your modified version of the script
  4. post the results

Note that the calls are dependent - there's a read on line 74 in which you need to enter the id of the list created by the previous call for use in the next call.

We completed this testing in other ways, and now have different ideas about a generic testing mechanism.