SaaS Toolkit - larz7/larzworksamples GitHub Wiki

Overview

The following instructions apply to the server back end service for a SaaS toolset and browser client app. Installing the toolkit and client app will enable you to manage workflows that power the SaaS product.

  • The back end service includes a proxy system that performs the following functions:
    • A simple proxy for forwarding requests to get around cross-domain restrictions.
    • A HMAC proxy for forwarding requests to integration services.
    • A S2S proxy for managing services through discovery and devadmin.
  • Monitoring of proxied requests to monitor health of workflow services.
  • Other miscellaneous back end services required by the Client.

Prerequisites

  • Make sure you have Java 7 or above installed.

  • Make sure you have a local instance of MongoDB version 2 or above running.

Run brew install mongodb.

brew install mongodb26
mongod --config /usr/local/etc/mongod.conf

If this is the first time you are running Mongo, create the service db and service-rw user.

mongo
> use client
> db.createUser({ user: "client-rw",
    pwd: "dummypass",
    roles: ["dbOwner"]
  })
>

If you already have an xxx-auth-xx user that you want to use, you will need to create a local services record that matches it.

mongo
> use client
> db.Account.insert({"email": "[email protected]",
  "enabled": true,
  "firstName": "yourFirst",
  "lastName": "yourLast",
  "description": "test",
  "team": "services",
  "role": "dev",
  "isTest": false,
  "businessId": NumberLong(0)
  })

$ git clone https://github.xxxxx.vxxxxx.net/xxxx/client.git
$ cd services
  • Use Jenkins to get your own certs for communicating with dev/qa and download them after the build is complete.
  • Create (or copy your own) config file in http/src/main/resources/local.conf.
  • Edit local.conf to make sure of the following.
    • Database db.mongodb.servers is pointed to localhost:27017
    • Authentication is disabled via webapp.service.auth.disabled
    • Point to your jenkins-generated certs via xxxxxx.ws.s2s and all its associated keys

Example local.conf, with keys in /opt/ssl_nonprod

db.mongodb.servers = ["localhost:27017"]
db.mongodb.database = "client"
db.mongodb.username = "client-rw"
db.mongodb.password = "dummypass"

If errors trigger, try the following as admin.

db.system.users.remove({})    <== removing all users
db.system.version.remove({}) <== removing current version
db.system.version.insert({ "_id" : "authSchema", "currentVersion" : 3 })

Point your browser to:

http://localhost:9000/client/

Initial Setup

Your first time loading the service/client you will need to disable auth.

  • First, go the the Admin/Managed Constants section and create an entry for business-id. You can copy the values from dev.
  • Then, find your account under Admin/Accounts and add the services/Admin/Super User role.
  • Once your account has been saved with the super admin role you can enable auth and restart the xxxx-service
  • Log out and back in again
  • Create a POST request to http://localhost:3000/admin/nav/section/createDefaults in order to generate the default navigation sections

Proxy Whitelist

The proxypass action allows the proxy of requests to other domains.

  • Allowed Domains
    • All CDNs available in the system (This list is cached)
    • A configurable list of additional domains (available in {env}.conf as additional_proxy_whitelist_domains)
  • Cached CDN domains can be reset manually by issuing a GET request to proxypass/whitelist-cache-reset
  • CDN domain cache duration is configurable via the cdn_white_list_cache_duration property in the application.conf

Proxy Config

  • The proxy config is cached for a configurable duration via webapp.service.proxy_configs_cache_duration (currently one hour)
  • The cache is invalidated when a record is added/updated/removed
  • Cache can also be manually invalidated via GET => /config/cache-reset

Caution: There may be multiple instances of the service running in production. Manually clearing cache may require invoking this action on the individual instances

  • Proxy config entries are tied to a specific build number
  • When a new build is first run, the proxy config settings from the previous release will be copied
  • When running locally, the "env" configuration value is used to store and obtain your proxy entries. This enables you to switch between dev and qa easily.
  • The default proxy configs can be loaded into cache manually via GET => /config/load-defaults/[filename]

Caution: There may be multiple instances of the service running. Manually loading the defaults may require invoking this action on the individual instances.