bluehatbrit / scaffold Goto Github PK

Need to get a Rails app going which can hook into Elastic Beanstalk and the other basic applications I'll need such as MySQL. I'll leave Redis and optional things like that for now. It would also help to understand the SSL deployment so I better check that out as well.

• Vagrant box with correct Ruby version to be the same as Elastic Beanstalk. (Ruby 2.3, Puma 2.1.6, RubyGem 2.5.1, nginx 1.8.1)
• Rails application on the latest version of Rails that the version of Ruby supports
• Elastic Beanstalk configurations (RDS env vars etc)
• Figure out SSL deployment (Certificate Manager - AWS)
• Subdomain setup to point to elastic beanstalk environment
• Travis / Wercker
• Figure out automated deployment

The list may be extended I'm sure.

Email confirmation is an important feature to help with password recovery. It'll also allow developers to hook into mailing lists in the future.

The flow should be something like this:

• User creates account
• Email is dispatched to them with a link to click to confirm their account details
• User cannot log in until the email has been verified
• Once verified, the user can log in as normal.

• Flag names must be hyphenated
• Flag names must not exceed the maximum length as described in the db

Create the initial project proposal to get a supervisor for the project and first stage approval for it. The proposal should include the following.

• 2 or 3 key-word phrases2 which encapsulate the nature of your project
• The intended client (if you have one)
• The main product (final deliverable) to be produced
  • and why your client needs it (if you have a client)
• Initial brief description of the final deliverable (e.g., web-based system
  providing the client with the ability to do XYZ)
• Method of approach
  • E.g., Likely software development process (e.g., waterfall, …)
  • E.g., Likely development platform (e.g., PHP & MySQL)
• Requirements for hardware, software (please note anything that is not
  currently available and for which you would require financial support) or other
  resources (e.g., external company support)

The following all need completing in the specified order to submit the project for grading.

Todo

• Purchase 3 sets of binding materials from the SU and a CD.
• Burn all project files onto the CD.
• Print 3 copies without appendices with colour (as required), 3 copies allows for a screw up.
• Ask someone at the library to demo how to bind them.
• Bind all three copies.
• Attach the CD to one of the copies.
• Submit the report with CD + one of the other reports into the Smeaton faculty office.
• Submit final PDF (including appendices) to SPMS.

Once all of these are done, the project will be completely submitted!

Getting a dumb build error saying it for some reason can't locate part of bcrypt. The yarn install seems to work fine but tests won't pick up the module.

Tried:

• Adding gcc-4.8 and g++-4.8 (both still there)
• Adding CXX environment variable
• Using mocha to run the tests rather than grunt

error:

  0 passing (354ms)
  2 failing
  1) User API "before all" hook: initModels:
     Error: Cannot find module '/home/travis/build/BlueHatbRit/scaffold/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
      at require (internal/module.js:20:19)
      at Object.<anonymous> (node_modules/bcrypt/bcrypt.js:6:16)
      at require (internal/module.js:20:19)
      at Object.<anonymous> (server/models/user.js:6:16)
      at require (internal/module.js:20:19)
      at models.forEach (server/models/index.js:15:27)
      at Array.forEach (native)
      at Object.exports.init (server/models/index.js:14:12)
      at Context.initModels (test/utils.js:6:12)

Captcha is a difficult problem with a deployable system like this, when creating google captcha accounts you must prove your ownership over the domain. As a result this will need some further configuration options and the ability to toggle it on / off.

Users need to be able to login to use most features of the API / web console, so it's important we create some API functions for this.

• Expose a HTTP API function for session creation.
• A function on the model which can take a email and password and verify that the credentials are correct.
• Generate a JsonWebToken and return it as the response.
• Create some middleware to detect a valid JsonWebToken given as Bearer Authorisation

We want to design the API before we build it, this will help to ensure we're going in the right direction.

Here's an idea of the routes we might want, they can be changed and updated as required.

API Routes to design + document

• Account creation
• Account add to group (Staff, etc)
• Session creation
• Session deletion - This may not be needed really since we're using json web tokens.
• Individual feature flag check for the authenticated user account
• All feature flag results for the authenticated user account

Depends on #20. Password reset is a vital feature for the 1.0 launch, if a user forgets their password or somehow loses control of their account we will want to ensure they can recover their password using the verified email address.

Once someone can create a feature flag, we need to be able list them ready for the editing feature.

Only users in the "staff" group should be able to see this page.

Bandiera had a cool approach. Build a string of the form:

#{feature_name}1_000_000#{user_id} then shove that into crc32 and get out an all numbers format, then modulo 100 and check it's value against the percentage.

This way we get a deterministic value that is user and feature specific, one which will always be the same. But we also don't need to create a huge table consisting of the results to ensure a each user gets the same result for a feature. Should the percentage change, then the result may be different.

const crc32 = require("crc-32")

var isEnabledForUser = crc32.str("myfeature-1_000_000-1235") % 100 < 40;

console.log(isEnabledForUser);

(https://runkit.com/58b18cf065aeab00137cc7d1/58b18db5e302c300142e0c9d)

The sample code above shows a possible way of doing this using the crc-32 npm library. Most libraries seem to return a hex value, this ones returning a number value which is perfect so we'll roll with that when needed.

The basic feature flag is a simple on/off feature flag. The developer should be able to:

• Assign the flag a name
• Give the flag a description
• Turn the flag on and off at will

Only users in the "staff" group should be able to access this feature!

Once someone can create a feature flag, we need to be able list them ready for the editing feature.

Only users in the "staff" group should be able to see this page.

Some users have commented that they'd like the ability to store some data along side a user, perhaps that might be game scores or specific user settings, etc.

This is bridging a bit into the realms of Parse now, so there are a few things to consider.

• What would be the best way for a developer to access this data form the scaffold API? Perhaps we they pass up some raw JSON and we store that in a MongoDB with object size restrictions.
• How would we implementing a scalable solution for this, maybe we could look at integrating Parse into the codebase to handle this for us properly.
• What security aspects do we need to consider to ensure this doesn't cause major problems?

This addition could significantly increase the usefulness of the product and would ensure they don't need to integrate other products to handle this data storage.

When Ry was reviewing my proposal for #1 he mentioned I'll probably need ethical approval. It's worth doing this now so I'm not waiting later on.

We can toggle everything except users to groups so far. Adding the ability to remove a user form a group would be quick, beneficial, and integral!

This might be a call made on system boot for a mobile app which returns the users access across the system. This can be used to reduce the number of calls required mobile networks etc.

It should return something like the docs show (below):

[
    {
        "id": 1234,
        "name": "super-great-thing",
        "description": "A super new great feature",
        "type": "simple"
        "hasAccess": true
    },
    {
        "id": 1244,
        "name": "dev-feature-unfinished",
        "description": "Some unfinished feature",
        "type": "group"
        "hasAccess": false
    }
]

Create a web page for account creation

• Create a route which will return an account creation page at /register or /signup etc.
• Create a web page which has an email and password + password confirmation box.
• Make a HTTP call with the given data to create the user account and return success / failed messages.
• Apply Miligram CSS to style the page.

The PID needs submitting so that I can begin the project, it will lay out an overview of the project including time frames and base concepts.

Users should be able to log into the web console, if they're staff they should later be able to access things such as the feature flag systems.

The API call should check the users credentials against a chosen feature flag, the call should then return a simple response as shown in the docs such as below.

{
    "id": 1234,
    "name": "super-great-thing",
    "description": "A super new great feature",
    "type": "simple"
    "hasAccess": true
}

It's worth considering if the request should actually return details of the flag, or just the status of the users access to the feature.

We won't be doing full designs, just wireframes / hand sketches for the web pages.

Screens

• Account creation
• Accounts list
• Feature flag list
• Feature flag creation
• Feature flag edit

Users and developers should be able to create accounts with their email address and a password.

• User table + model
• Model hashes password on creation
• API call (non http)
• Web page functionality
• Web page styles

Notes:

• Use an email to identify users which must be unique