You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

90 lines
3.8 KiB

  1. <?php ob_start() ?>
  2. ## The Micropub Endpoint
  3. After a client has obtained an access token and discovered the user's Micropub endpoint
  4. it is ready to make requests to create posts.
  5. ### The Request
  6. This is not intended to be a comprehensive guide to Micropub, and only includes the
  7. fields that this client sends.
  8. The request to create a post will be sent with as a standard HTTP form-encoded request
  9. The example code here is written in PHP but the idea is applicable in any language.
  10. The request will contain the following POST parameters:
  11. * `h=entry` - Indicates the type of object being created, in this case an <a href="http://indiewebcamp.com/h-entry">h-entry</a>.
  12. * `content` - The text content the user entered, in this case the caption on the Instagram photo.
  13. * `category` - A comma-separated list of tags that you entered
  14. * `location` - A "geo" URI including the latitude and longitude of the photo if included. (Will look like `geo:37.786971,-122.399677;u=50`, where u=50 indicates the "uncertainty" of the location in meters)
  15. * `in-reply-to` - If set, this is a URL that the post is in reply to
  16. The request will also contain an access token in the HTTP `Authorization` header:
  17. <pre>
  18. Authorization: Bearer XXXXXXXX
  19. </pre>
  20. ### Verifying Access Tokens
  21. Before you can begin processing the photo, you must first verify the access token is valid
  22. and contains at least the "post" scope.
  23. How exactly you do this is dependent on your architecture. You can query the token endpoint
  24. to check if an access token is still valid. See [https://tokens.indieauth.com/#verify tokens.indieauth.com]
  25. for more information.
  26. Once you have looked up the token info, you need to make a determination
  27. about whether that access token is still valid. You'll have the following information
  28. at hand that can be used to check:
  29. * `me` - The user who this access token corresponds to.
  30. * `client_id` - The app that generated the token.
  31. * `scope` - The list of scopes that were authorized by the user.
  32. * `issued_at` - The date the token was issued.
  33. Keep in mind that it may be possible for another user besides yourself to have created
  34. an access token at your token endpoint, so the first thing you'll do when verifying
  35. is making sure the "me" parameter matches your own domain. This way you are the only
  36. one that can create posts on your website.
  37. ### Validating the Request Parameters
  38. A valid request to create a post will contain the parameters listed above. For now,
  39. you can verify the presence of everything in the list, or you can try to genericize your
  40. micropub endpoint so that it can also create [http://ownyourgram.com/creating-a-micropub-endpoint photo posts].
  41. At a bare minimum, a Micropub request will contain the following:
  42. * `h=entry`
  43. * `content`
  44. The access token must also contain at least the "post" scope.
  45. ### The Response
  46. Once you've validated the access token and checked for the presence of all required parameters,
  47. you can create a post in your website with the information provided.
  48. If a post was successfully created, the endpoint must return an `HTTP 201` response with a
  49. `Location` header that points to the URL of the post. No body is required for the response.
  50. <pre>
  51. HTTP/1.1 201 Created
  52. Location: http://example.com/post/100
  53. </pre>
  54. If there was an error, the response should include an HTTP error code as appropriate,
  55. and optionally an HTML or other body with more information. Below is a list of possible errors.
  56. * `HTTP 401 Unauthorized` - No access token was provided in the request.
  57. * `HTTP 403 Forbidden` - An access token was provided, but the authenticated user does not have permission to complete the request.
  58. * `HTTP 400 Bad Request` - Something was wrong with the request, such as a missing "h" parameter, or other missing data. The response body may contain more human-readable information about the error.
  59. <?= Markdown(ob_get_clean()) ?>