From 3f82ec2f757c62c25a31b461e0a0cddc14886117 Mon Sep 17 00:00:00 2001
From: Aaron Parecki <aaron@parecki.com>
Date: Sat, 24 May 2014 14:41:21 -0700
Subject: Working app! Copied signin logic from OwnYourGram. New "post"
 interface for writing a simple text post. Also supports browser geolocation.

---
 views/creating-a-micropub-endpoint.php | 90 ++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)
 create mode 100644 views/creating-a-micropub-endpoint.php

(limited to 'views/creating-a-micropub-endpoint.php')

diff --git a/views/creating-a-micropub-endpoint.php b/views/creating-a-micropub-endpoint.php
new file mode 100644
index 0000000..617b52f
--- /dev/null
+++ b/views/creating-a-micropub-endpoint.php
@@ -0,0 +1,90 @@
+<?php ob_start() ?>
+## The Micropub Endpoint
+
+After a client has obtained an access token and discovered the user's Micropub endpoint
+it is ready to make requests to create posts.
+
+### The Request
+
+This is not intended to be a comprehensive guide to Micropub, and only includes the 
+fields that this client sends.
+
+The request to create a post will be sent with as a standard HTTP form-encoded request
+The example code here is written in PHP but the idea is applicable in any language.
+
+The request will contain the following POST parameters:
+
+* `h=entry` - Indicates the type of object being created, in this case an <a href="http://indiewebcamp.com/h-entry">h-entry</a>.
+* `content` - The text content the user entered, in this case the caption on the Instagram photo.
+* `category` - A comma-separated list of tags that you entered
+* `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)
+* `in-reply-to` - If set, this is a URL that the post is in reply to
+
+The request will also contain an access token in the HTTP `Authorization` header:
+
+<pre>
+Authorization: Bearer XXXXXXXX
+</pre>
+
+
+### Verifying Access Tokens
+
+Before you can begin processing the photo, you must first verify the access token is valid
+and contains at least the "post" scope.
+
+How exactly you do this is dependent on your architecture. You can query the token endpoint
+to check if an access token is still valid. See [https://tokens.indieauth.com/#verify tokens.indieauth.com]
+for more information.
+
+Once you have looked up the token info, you need to make a determination
+about whether that access token is still valid. You'll have the following information
+at hand that can be used to check:
+
+* `me` - The user who this access token corresponds to.
+* `client_id` - The app that generated the token.
+* `scope` - The list of scopes that were authorized by the user.
+* `issued_at` - The date the token was issued.
+
+Keep in mind that it may be possible for another user besides yourself to have created
+an access token at your token endpoint, so the first thing you'll do when verifying 
+is making sure the "me" parameter matches your own domain. This way you are the only
+one that can create posts on your website.
+
+
+### Validating the Request Parameters
+
+A valid request to create a post will contain the parameters listed above. For now,
+you can verify the presence of everything in the list, or you can try to genericize your 
+micropub endpoint so that it can also create [http://ownyourgram.com/creating-a-micropub-endpoint photo posts].
+
+At a bare minimum, a Micropub request will contain the following:
+
+* `h=entry`
+* `content`
+
+The access token must also contain at least the "post" scope.
+
+
+### The Response
+
+Once you've validated the access token and checked for the presence of all required parameters,
+you can create a post in your website with the information provided.
+
+If a post was successfully created, the endpoint must return an `HTTP 201` response with a
+`Location` header that points to the URL of the post. No body is required for the response.
+
+<pre>
+HTTP/1.1 201 Created
+Location: http://example.com/post/100
+</pre>
+
+If there was an error, the response should include an HTTP error code as appropriate, 
+and optionally an HTML or other body with more information. Below is a list of possible errors.
+
+* `HTTP 401 Unauthorized` - No access token was provided in the request.
+* `HTTP 403 Forbidden` - An access token was provided, but the authenticated user does not have permission to complete the request.
+* `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.
+
+
+
+<?= Markdown(ob_get_clean()) ?>
-- 
cgit v1.2.3