Name: service-frontend-alpha
Owner: HM Land Registry
Description: Front end app for the land registry service
Created: 2014-07-18 13:53:27.0
Updated: 2015-02-02 16:46:43.0
Pushed: 2015-02-02 16:46:43.0
Homepage: null
Size: 21408
Language: Python
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
clone git@github.com:LandRegistry/service-frontend.git
ervice-frontend
intall -r test_requirements.txt
Then run:
est
Local development config:
rt SETTINGS='config.DevelopmentConfig'
rt DATABASE_URL='postgresql://localhost/service_frontend'
rt AUTHENTICATED_SEARCH_API='http://search-api.landregistry.local'
rt DECISION_URL='http://decision.landregistry.local'
rt MATCHING_URL='http://matching.landregistry.local'
rt OWNERSHIP_URL='http://ownership.landregistry.local'
rt INTRODUCTION_URL='http://introductions.landregistry.local'
rt CASES_URL='http://cases.landregistry.local'
rt HISTORIAN_URL='http://historian.landregistry.local'
rt OS_API_KEY='no-key'
rt REDIS_URL='redis://user:@localhost:6379'
rt PERMANENT_SESSION_LIFETIME=60 # minutes picked by random inspiration
rt VIEW_COUNT=50
rt VIEW_COUNT_ENABLED=True
rt SECRET_KEY='localdev-not-secret'
rt SECURITY_PASSWORD_HASH='bcrypt'
Note in local dev port is assigned by dev env scripts
For production
=[SOME NUMBER]
INGS='config.Config'
BASE_URL='postgresql://user:password@db_host:port:db_name'
above with real values]
There's an intial migration script in the project created using Flask-Migrate so you just need to call the following
on manage.py db upgrade
If you need to run this on Heroku, use this command:
ku run python manage.py db upgrade --app lr-service-frontend
Note that this is run automatically as part of the deploy from travis
Run the upgrade command whenever you have additional migrations
Run in dev mode to enable app reloading
run-app
Run tests
run-unit-tests
First activate the virualenv for this project
Locally:
eate-user-for-integration-tests.sh
On Heroku :
ku run python manage.py create_user --email='citizen@example.org' --password='dummypassword' --name='Walter White' --dob='1959-09-07' --gender='M' --current_address='1 High St, London, N1 4LT' --previous_address='2 High St, London, SW2 1LT' --app lr-service-frontend
This app runs on PORT 8007
User accounts and login
This application has a notion of users in a form that would not need to exist if/when integration with GOV.UK Verify happens.
In this application a user logs in with a user name and password. That is used to lookup in the applications local database a set of personal data (name, date of birth, gender, current address and previous address). This personal data set is used to lookup a “matching” record in the matching service.
If we were to use GOV.UK Verify the login form and user name + password check happens in an external service (GOV.UK Verify) which then returns the personal data set to use for matching. Make sense?
We took a shortcut here by being handwavy about where the personal data comes from. Since we did not do GOV.UK Verify integration and we did not want to build a stub GOV.UK Verify in the alpha, it really did not matter that we just held our fake set of personal data in the application db proper.
When GOV.UK Verify integration comes about the user object as is would mutate into some sort of login record table. The login view method would still make a call out to matching but the input to that call would be something that came from GOV.UK Verify.
ackaging
ild.sh
This will create a virtualenv, install service-frontend into that env. Then it will set virtualenv paths to match the eventual installation directory of the debian package that is the output of build.sh.
Note The packaging of a virtualenv using fpm may soon be much easier depending on outcome of this
The result of running ./build.sh is debian package will be created in packaging called service-frontend. The package has a basic upstart config, empty pre and post install and remove scripts. For the moment the installer is set to install to /opt/alpha/service-frontend. Change as required. Also post install does not set ownership or permissions on the installed package.
Before installing in a production box you should:
dpkg -i service-frontend_0.1_all.deb
Then run
start service-frontend
Note that this assumes you have set all the correct environment variables.
To uninstall
dpkg -r service-frontend
At the moment the migration version files and manage.py are included in packages and live in installation directory. I would for the moment run these after the install (and under control of configuration management tool) before running the service.
opt/alpha/service-frontend
on manage.py db upgrade