863341 - (my.webmaker.org) [Meta] Webmaker User Domains

Status: RESOLVED FIXED

(Webmaker Graveyard :: General, enhancement)

Description

[David Humphrey (:humph)]

This is a meta bug for allowing Webmaker users to publish content to a specified sub-domain (and perhaps real domain down the road).  Top-level goals, some near term, some longer term, include:

* Webmaker tools, sites, APIs, etc. are hosted from *.webmaker.org
* Webmaker content (user published content from Webmaker tools) is hosted on a new, secondary, with user supplied subdomains (e.g., [user].[new domain].org), following the github.com vs. [user].github.io model.
* At some point we might move toward helping users register and host to their own arbitrary domain.
* Rely on domain separation and origin checks in the browser to help us move toward including <script> in user published content.  This can be done in stages, and the security of such actions included in the scope of educating web makers about how to build things on and for the web.

Initial meeting notes can be found at https://etherpad.mozilla.org/webmaker-user-domains, see especially line 32+.  For further details, see dependent bugs.

Comment 1

[David Humphrey (:humph)]

FWIW, github's discussion of the reasons behind github.io, with some good technical insights about the decision and process they took.

https://github.com/blog/1452-new-github-pages-domain-github-io

Comment 2

[David Ascher (:davida)]

Also see this older piece from Google on a similar topic:

  http://googleonlinesecurity.blogspot.com/2012/08/content-hosting-for-modern-web.html

Comment 3

[David Humphrey (:humph)]

CSP was another thing we discussed, and Github is blogging about that today:

https://github.com/blog/1477-content-security-policy

Comment 4

[Jon Buckley]

Alright, here's what we need to do to have fully-functioning user subdomains.

First, some definitions I'll use throughout this novel:

Friendly URLs - The URLs that the user sees - https://[subdomain].mywebmaker.org/[title] - IE https://jon.mywebmaker.org/my-cool-project (they defined a title), https://jon.mywebmaker.org/36 (they did not define a title)

Content URLs - The URLs that the tools write out too - http://[bucket].[s3-website-region].amazonaws.com/[webmaker-user-id]/[tool]/[application-specific-ID] - IE http://mywebmaker-org.s3-website-us-east-1.amazonaws.com/1234/popcorn/36, http://mywebmaker-org.s3-website-us-east-1.amazonaws.com/1234/thimble/42

When a user hits the publish button, the tool will:

1) Publish the project to S3 at the content URL
2) Publish the content URL to a URL shortener
3) Receive the friendly URL from the URL shortener, and display it to the user

When a user visits a friendly URL, the URL shortener will:

1) Look up the content URL in a database
2) Proxy the content located at the content URL to the client

Another comment to come as to why this is the best solution

Comment 5

[Jon Buckley]

Okay, so the reason I decided to go with a combination URL shortener/proxy is twofold:

1) I wanted each tool to not have to worry about overwriting another tools content; S3 doesn't provide any sort of atomic writes. We need to provide some sort of mediator that can prevent write conflicts between different tools.
2) The friendly URL doesn't have enough information to transform itself to a content URL

Scott and I also brainstormed using iframes stored at the friendly URL, but that has problems with <meta> tags and it's less preferable than proxying the data directly.

Comment 6

[Jon Buckley]

Pomax and I just though of another idea; we just need something in front of S3 that provides a consistent view of "does the S3 bucket have this thing stored or not?"

This could be the MakeAPI, or some standalone mediator, or anything that sits in front of S3 really.

--

After talking to humph, and looking at the time we have available this week, we'll just append an application-specific key ("p" for popcorn, "t" for thimble, etc). More achievable in less than a weeks time.

Comment 7

[Jon Buckley [:jbuck]]

All metabugs DONE!