Nabil Ashraf nabilashraf

Keystone 5: Secure Cookies and Reverse Proxies

Can't sign in, eh?

TL;DR

When...

Keystone sessions are being used (eg. for authentication)
secureCookies Keystone config is true (the default when NODE_ENV is 'production')

Bitnami applies the following default permissions to WordPress files and directories:

Files and directories are owned by user bitnami and group daemon.
Directories are configured with permissions 775 by default.
Files are configured with permissions 664 by default.
The wp-config.php file is configured with permissions 640.

Link

If permissions are wrong, use the chmod or chown commands to restore them to their initial state. For example, if TARGET is the WordPress application folder:

This is an example of how to scaffold API endpoints to list / get / create / update / delete Posts in a Keystone website.

It's a modification of the default project created with the yo keystone generator (see https://github.com/JedWatson/generator-keystone)

Gists don't let you specify full paths, so in the project structure the files would be:

routes-index.js        -->    /routes/index.js         // modified to add the api endpoints
routes-api-posts.js    -->    /routes/api/posts.js     // new file containing the Post API route controllers

Creating new Field Types for KeystoneJS

We're currently working on making it easier to add new field types to KeystoneJS as plugins.

In the meantime, if you'd like to work on your own field type, hopefully this guide will point you in the right direction.

Keystone fields require the following:

a {fieldType}.js file in ./lib/fieldTypes that controls the field and encapsulates options support, underscore functions, validation and updating
the {fieldType}.js file needs to be included by ./lib/fieldTypes/index.js

I've developed a useful feature in KeystoneJS that lets you populate a relationship from either side, while only storing the data on one side, and am looking for feedback on whether it is something that could / should be brought back into mongoose itself. (It might be possible to add as a separate package but I suspect there'd be too much rewriting of mongoose internals for that to be a good idea).

I've added this as an issue in mongoose for consideration: #1888 but am leaving this gist in place because the examples are easier to read.

I've used Posts and Categories as a basic, contrived example to demonstrate what I'm talking about here; in reality you'd rarely load all the posts for a category but there are other real world cases where it's less unreasonable you'd want to do this, and Posts + Categories is an easy way to demo it.

The problem

The built-in population feature is really useful; not just for

	User.aggregate([
	{
	/* Filter out users who have not yet subscribed */
	$match: {
	/* "joined" is an ISODate field */
	'subscription.joined': {$ne: null}
	}
	},
	{
	/* group by year and month of the subscription event */

	printf "****************************************************************************************\n"
	printf "Hi, if you have installed Android SDK, then add this path to your system environment: \n"
	printf "Local\\Android\\Sdk\\emulator \n"
	printf "****************************************************************************************\n"
	printf "You can see the list of Available virtual Devices Below:\n"
	emulator -list-avds \| cat -n
	printf "Select AVD number: "
	read index
	avd=$(emulator -list-avds \| sed "${index}q;d")
	echo "Selected $avd"

	// Construct Single Node
	class Node {
	constructor(data, next = null) {
	this.data = data;
	this.next = next;
	}
	}

	// Create/Get/Remove Nodes From Linked List
	class LinkedList {