Consent-Based Verification (CBV) is an approach to allow benefit applicants to opt to verify their income via products that pull directly from payroll providers. This repository implements a product to demonstrate this technology for testing and validation purposes.
If you're new to Rails, see the Getting Started with Rails guide for an introduction to the framework.
- All of these steps need to be run within the
appdirectory - Install Xcode Command Line Tools
- Install homebrew dependencies:
brew bundle- rbenv
- nodenv
- redis
- jq
- PostgreSQL
- Dockerize
- ADR Tools
- Graphviz: brew install graphviz
- Chromedriver
- Chromedriver must be allowed to run. You can either do that by:
- The command line:
xattr -d com.apple.quarantine $(which chromedriver)(this is the only option if you are on Big Sur) - Manually: clicking "allow" when you run the integration tests for the first time and a dialogue opens up
- The command line:
- Chromedriver must be allowed to run. You can either do that by:
- Ngrok: brew install ngrok/ngrok/ngrok
- Sign up for an account: https://dashboard.ngrok.com/signup
- run
ngrok config add-authtoken {token goes here}
- Set up rbenv and nodenv:
echo 'if which nodenv >/dev/null 2>/dev/null; then eval "$(nodenv init -)"; fi' >> ~/.zshrcecho 'if which rbenv >/dev/null 2>/dev/null; then eval "$(rbenv init -)"; fi' >> ~/.zshrc- Close & re-open your terminal
- Install Ruby:
rbenv install - Install NodeJS
nodenv install - Install Ruby dependencies:
bundle install - Install JS dependencies
nodenv rehash
- Start postgres & redis:
brew services start postgresql@12brew services start redis
- Get development credentials from 1Password, search for "CBV Rails Secrets" and copy its ".env.development.local" section into a file called that in the "app" directory.
- Create database:
bin/rails db:create - Run migrations:
bin/rails db:migrate - Run the development server:
bin/dev - Visit the site: http://localhost:3000
Environment variables can be set in development using the dotenv gem.
Any changes to variables in .env that should not be checked into git should be set in .env.local.
If you wish to override a config globally for the test Rails environment you can set it in .env.test.local.
However, any config that should be set on other machines should either go into .env or be explicitly set as part
of the test.
To run locally, use bin/dev
When beginning work on a feature, create a new branch based off of main and make the commits for that feature there.
We intend to use short-lived branches so as to minimize the cost of integrating each feature into the main branch.
TBD
TBD
The system's Content-Security-Policy header prevents <script> and <style> tags from working without further
configuration. Use <%= javascript_tag nonce: true %> for inline javascript.
See the CSP compliant script tag helpers ADR for more information on setting these up successfully.
We use the gem i18n-tasks to manage locale files. Here are a few common tasks:
Add missing keys across locales:
$ i18n-tasks missing # shows missing keys
$ i18n-tasks add-missing # adds missing keys across locale files
Key sorting:
$ i18n-tasks normalize
Removing unused keys:
$ i18n-tasks unused # shows unused keys
$ i18n-tasks remove-unused # removes unused keys across locale files
For more information on usage and helpful rake tasks to manage locale files, see the documentation.
- Tests:
bundle exec rake spec - Ruby linter:
bundle exec rake standard - Accessibility scan:
./bin/pa11y-scan - Dynamic security scan:
./bin/owasp-scan - Ruby static security scan:
bundle exec rake brakeman - Ruby dependency checks:
bundle exec rake bundler:audit - JS dependency checks:
bundle exec rake npm:audit
Run everything: bundle exec rake
When new pages are added to the application, ensure they are added to ./.pa11yci so that they can be scanned.
To enable automatic ruby linting and terraform formatting on every git commit follow the instructions at the top of .githooks/pre-commit
GitHub actions are used to run all tests and scans as part of pull requests.
Security scans are also run on a scheduled basis. Weekly for static code scans, and daily for dependency scans.
TK
TK
TK
TK
TK
The New Relic Ruby agent has been installed for monitoring this application.
The config lives at config/newrelic.yml, and points to a FEDRAMP version of the New Relic service as its host. To access the metrics dashboard, you will need to be connected to VPN.
To get started sending metrics via New Relic APM:
- Add your New Relic license key to the Rails credentials with key
new_relic_key. - Optionally, update
app_nameentries inconfig/newrelic.ymlwith what is registered for your application in New Relic - Comment out the
agent_enabled: falseline inconfig/newrelic.yml - Add the Javascript snippet provided by New Relic into
application.html.erb. It is recommended to vary this based on environment (i.e. include one snippet for staging and another for production).
Digital Analytics Program (DAP) code has been included for the Production environment, associated with GSA.
If Iv Cbv Payroll is for another agency, update the agency line in app/views/layouts/application.html.erb
See CODEOWNERS.md for some information on repo structure.
Documentation is currently stored in CMS Confluence: https://confluenceent.cms.gov/display/SFIV/Consent-based+Verification+%28CBV%29+for+Payroll
Our ADRs are stored in CMS Confluence: https://confluenceent.cms.gov/pages/viewpage.action?pageId=693666588
See CONTRIBUTING.md.
The CBV team is taking a community-first and open source approach to the product development of this tool. We believe government software should be made in the open and be built and licensed such that anyone can download the code, run it themselves without paying money to third parties or using proprietary software, and use it as they will.
We know that we can learn from a wide variety of communities, including those who will use or will be impacted by the tool, who are experts in technology, or who have experience with similar technologies deployed in other spaces. We are dedicated to creating forums for continuous conversation and feedback to help shape the design and development of the tool.
We also recognize capacity building as a key part of involving a diverse open source community. We are doing our best to use accessible language, provide technical and process documents, and offer support to community members with a wide variety of backgrounds and skillsets.
See GOVERNANCE.md
If you have ideas for how we can improve or add to our capacity building efforts and methods for welcoming people into our community, please let us know by sending an email to: ffs at nava pbc dot com. If you would like to comment on the tool itself, please let us know by filing an issue on our GitHub repository.
We adhere to the CMS Open Source Policy. If you have any questions, just shoot us an email.
Submit a vulnerability: Unfortunately, we cannot accept secure submissions via email or via GitHub Issues. Please use our website to submit vulnerabilities at https://hhs.responsibledisclosure.com. HHS maintains an acknowledgements page to recognize your efforts on behalf of the American public, but you are also welcome to submit anonymously.
For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see SECURITY.md.
This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication as indicated in LICENSE.
All contributions to this project will be released under the CC0 dedication. By submitting a pull request or issue, you are agreeing to comply with this waiver of copyright interest.
See CODEOWNERS.md