• admin app per tenant config - coupled to https admin website
• infra
• website
  • website docs
  • website blog
  • website front
• free alpha testing

http://python-eve.org/

• google: https://developers.google.com/accounts/docs/OAuth2
• github
• twitter
• amazon
• https://oauthlib.readthedocs.org/en/latest/oauth2/oauth2.html
• stack A4's

http://tools.ietf.org/html/draft-dejong-remotestorage-01

We need some centralized, HA service in which ACCURACY is paramount (over speed)

Zookeeper or Heroku''s https://github.com/ha/doozerd

Based on top of oauth2

http://openid.net/connect/

http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

• https://github.com/FrankHassanabad/Oauth2orizeRecipes/wiki/OAuth2orize-Authorization-Server-Tests
• http://blog.modulus.io/nodejs-and-hapi-create-rest-api

• oAuth Flow designs
• usecases(commercial + technical)
• usecases -> oauth flow designs
• Requirements (complete)
• Functional Design complete reqs
• split requirements to MVP and subsequent iterations

Heroku is now facing problems with this.

They do random routing instead of least connection routing, bc. least connection routing would not scale.

So why would that be the case? Probably due to the cap theorem, you need to make tradeoffs, between accuracy and scalability:

A good discsusion on HN,
link with part of the discussion here:
https://news.ycombinator.com/item?id=5490690

http://janrain.com/products/engage/

https://www.grc.com/sqrl/sqrl.htm

hackernews coverage:
https://news.ycombinator.com/item?id=6484577

Another in this space:
https://getclef.com/

Is there really custom-controlled code needed? can't all things be done declaratively that you'd normally want done in a controller?

Especially when we get application-workflow done declaratively (or using sagas which transfers the flow to the domain-model), in addition to all the operations on single domain-models we have covered pretty much everything?

per-route:

• defaults (middleware)
• validation (middleware)
• authentication (middleware)
• authorization (middleware)
• from payload to repo (translation)
• from repo to view (translation). I.e: view-model

http://www.simplecloud.info/

2-sided marketplaces need to get traction on 1 side first usually. There's your classic chicken/egg problem. One of the best ways to get this going is piggybacking on an existing marketplace.

AirBnB did this famously by having houseowners crosspost automatically on craigslist getting the supply stream going attracting customers.

So how about you piggyback on AirBnB, that's only fair right? :) I've visited AirBnB houses frequently, but always forget to leave a tip although a wanted to - seriously. How about you start targeting AirBnB homeowners to sign you up for this very purpose? They could leave a note in their house to politely ask for a tip (to pay through your app) if they feel inclined to.

options

• sms: nr -> tenant + amount - COSTLY
• using Stripe
  • @tipping.io with $ optionally prefilled (note: you need to pay through cc or paypal)
  • auto-receive link
  • follow link: tenant-created profile
    • thanking them
    • some cheesy choosable picture
    • amount to select
    • OK
    • payment method
    • OK

15% charge (can go down to 12% if we must)

for 15% using stripe

$5 -> $0.75 of which 0.445 goes to Stripe (2.9% + 0.30 cent) -> leaving $0.305
$10 -> $1.5 of which 0.59 goes to Stripe -> leaving $0.91
$15 -> $2.25 of which 0.735 goes to Stripe -> leaving $1.515

• passport for HAPI - https://github.com/spumko/travelogue
• https://github.com/Mashape/mashape-oauth
• passport
• alternative to digest and supported by HAPI (some author I think) https://github.com/hueniverse/hawk
• from author of hawk comes Oz which is more complete (reimplements something similar to oAuth) : https://github.com/hueniverse/oz

Example of auth in Hapi using the above:
hapijs/hapi#964

• oAuth2orize test
• Hapi test
• oAuth2orize + hapi test
• oAuth2orize + hapi test + integration DryWall

As posted to http://launchsky.com/

Your requirements on Access Management will change over time.

Be it from a shift of roles in your business or simply because of A/B testing different price (and associated functionality) tiers of your new awesome SaaS.

Having to adapt hardcoded Access Management policies in a multitude of APIs and apps is error-prone. Hardly the area in which you, startup and seasoned business alike, can allow to make even the smallest mistake.

We believe you'd sleep more comfortable knowing there was a way in which you could easily decouple access-related functionality from your apps and manage it in a centralized, controllable and adaptable way. All this, without needing to touch your App or API (after the initial setup that is).

Entitled.io takes care of:

• Authentication, sign-up and recovery flows (including hosted, white-labeled forms)
• Flexible Authorization, allowing for point-and-click answering "which users are entitled to which resources?"
• Identity Management or the issue of "Securely storing your users". Either connect to your internal Identity Solution (LDAP, AD, etc.) or use our hosted solution.

All policies and related functionality are hot (re)configurable through an API or web-dashboard. The latter enables business to turn the knobs, although it's a pleasure to use for developers too.

As Entitled.io supports standards like oAuth2, Uma, and Scim, you're ensured of good open-source clients for your language of choice, in order to correctly connect your App or API to Entitled.io. Moreover, we're planning on open-sourcing clients / client add-ons when needed.

Interested in your thoughts.

Implement using Policies as a middleware.

• complete before routes
• route-specific
• declarative

should support things such as:

Policies don't seem to be cover a simple use case of returning a subset of data. i.e. Take a simple example
Users model
Groups model, which is a nested set
Users can belong to many groups
Users can see all other users, in the same group or child groups

Similar to #7 (discussing controllers), would it be possible to have declarative business logic? Especailly when we have a notion of a declarative workflow a lot should be possible. (where leaf-nodes should result on repo-actions)

e.g: the following should be possible:

• Domain Model: Fat model with business logic, operates on a single or multiple data entities (i.e. entity A in a given state than action on entity B)
• Data Model: Storage-aware model, logic contained within a single entity relates only to that entity (i.e. if field a then field b) -> EAGER CALCULATED FIELDS. (lazy would be on RESOURCE, i.e: calculate JIT)

• admin app per tenant config - coupled to https admin website
• infra
• website
  • website docs
  • website blog
  • website front
• free alpha testing

read/write load will always be distributed for every customer: even the cheapest package will do HA (?).

Threfore there's a possibility to distributes read-clusters in such a way that each customer will share the least possible nodes with any other customer, therfore minimizing the overall trouble any customer can get from any other.

Or distribution of nodes is a mincost-function over clusters. Something like minclique

• stormpath (hosted)

identity management

Known SCIM 1.1 implementations

Experimental implementations of SCIM 2.0
The 2.0 specification is still under development, deploy implementations based on SCIM 1.1.