We consider adding incrementally more control over the creation of subdomains within a wiki farm. A Register plugin would be offered on a claimed site that would manufacture and possibly pre-claim subdomain sites.
Markup would describe fields, validation rules, and any other policy parameters. This information would go into the owner.json for the new site. Mockups follow.
Offering some fields may make the server operator responsible for legal restrictions on personally identifiable information. wikipedia
The plugin could be the only way to create subdomains if the current create-on-reference mechanism were disabled.
A server-side plugin would validate the request, probably as a post, probably to the origin server. Specially relaxed CORS behavior might be possible.
A successful registration will open the new welcome page in a new browser tab. Will need work on app startup and flag initialization.
The plugin could be configured to make subdomains owned by the same owner as the hosting site.
The plugin could be configured to only make subdomains for the logged-in owner of the site or the administrator of the server.
The plugin could be configured to use specific templates for manufacturing one or more pages in the new site.
The plugin could be configured to add new sites to a Roster, or might serve as roster itself somehow.
The plugin could create a friendly recovery email ready to post given only an email address.
var mail = "mailto:firstname.lastname@example.org?subject=New Mail&body=Mail text body"; var mlink = document.createElement('a'); mlink.setAttribute('href', mail); mlink.click();
We'll experiment with new sites with friendly security. One version will make subdomains owned by the same owner as the plugin. The other will create new sites and generate an email invitation/secret that the receiver can protect as they see fit. github
make a new subdomain owned by this site's owner
We consider keywords that will select fields and policy. We list what we have been thinking and then study that for logic and completeness.
Say DOMAIN to prompt for subdomain name.
Say LOGIN, EMAIL to prompt for operational identification.
Say NAME, PURPOSE to prompt for who and why.
Say CODE to prompt for invitation code to continue.
Say REQUIRED before any prompt to make it manditory.
Say WELCOME, WHO, WHY to specify page templates.
Say INVITE to specify page with invitation text.
Plugin will need to revalidate form parameters server-side which will be hard to do right since we're using html5 validation unavailable on the server. This must be a common problem with html5, no?
First Remote Registration that worked, sort of. There is confusion as to which domain is enlarged. This could depend on markup. Add a heading like Plugmatic's.