-
Notifications
You must be signed in to change notification settings - Fork 2
Walkthrough
Here, you will find how to run a Django application with Django_pph installed on it.
# Getting the test applicationThe sources for this tutorial can be downloaded here.
### Getting the dependencies In order to be able to run this walkthrough you will need the following:- sqlite3. You can install it with your distributions package manager or here. This is only necessary if you want to inspect the database.
- Django and pycrypto installed. You can install them through pip.
After downloading the sources, make a new directory for them and copy the zip file over.
$ mkdir testing_pph
$ mv test_project.zip testing_pph
$ cd testing_pph
Now, uncompress the zip file there and delete it.
$ unzip test_project.zip
...
$ rm test_project.zip
Now you have all the sources ready for the application. Before we run anything, let's inspect what we have inside.
### Inspecting the contents of the zip fileThe zip file contains all the sources ready for a test migration and a running server. Let's run ls to check what's in there
$ ls -1
db.sqlite3
db.sqlite3.bak
django_pph
emptyproject
manage.py
From this tree, we can see that there are only two subfolders: django_pph and emptyproject. We can also see that there are two copies of the database (db.sqlite3 and db.sqlite3.bak). Along with these, there is also the manage.py script. This is how an empty installation of Django with django_pph looks like.
### Inspecting the databaseIn case you want to verify the status of the database, run
$ sqlite3 db.sqlite3
> select username, password from auth_user;
To see that the passwords are originally pbkdf2_sha256.
Now, we will migrate the database to django_pph befor continuing.
# Migrating the databaseAfter inspecting its contents, you can migrate the database with
$ ./manage.py createcachetable share_table
$ ./manage.py setup_store python django test1
The command we just called with setup a PPH store with the users django, python and test1 as threshold accounts. The rest of the accounts are defaulted as thresholdless and they can be updated (or promoted) if so desired at a later time.
You can verify the migration was successful if you run the SQL query again; you will see that the new algorithm string "pph" and the sharenumber field has been added. This sharenumber field is used to identify accounts that are threshold or thresholdless.
# Running the applicationNow you can run the server and see how it behaves. To to this, run:
$ ./manage.py runserver
This, basically, tells the server to listen in localhost at port 8000 . If you want your server to listen in all interfaces, run the same command with 0.0.0.0:8000 as an argument.
You can test log in in the following urls:
- localhost:8000/login (for all types of accounts)
- localhost:8000/admin (for staff members only)
Next, we will log in into the admin console
### The administration portalOpen a browser and navigate to localhost:8000/admin. You will see the default administration panel for Django applications.
Log into the admin portal with santiago/santiago or any other admin account and play around. You can verify the information for each user here, and you will be able to see the information about their hash.
### Creating usersYou can create new users by logging in and clicking in the "add" button to the right of the Users field. You will have to fill up a username and a password.
After you create a new user in the admin portal, you will be able to see the status of their password string, and realize that newly created accounts default to thresholdless accounts. Let's make this account a threshold one.
### Promotion and demotion of usersTo make the new account a threshold one, fire up another terminal and run:
$ ./manage.py promote_user [username]
You can use one of the testN accounts for this if you want (N is 1-5). Remember that their password is the same as their username.
Now, go back to the admin portal and verify that his sharenumber and hash has changed to something different. You can see this by clicking on "Users" and then in the username on the list that shows up.
You can do the same to test user demotion. In the second terminal, run:
$ ./manage.py demote_user [username]
And see that his values should be returning to those of a thresholdless account.
Finally, let's see how an account looks like when it is created inside a locked store.
### Creating users in a locked store.First, let's stop the running server in the original terminal by pressing Ctrl+C.
For convenience, there is another command called "lock_store" ,so you can try partial verification and alerts. Run the following command:
$ ./manage.py lock_store
After running the lock_store command, you can restart the server with:
$ ./manage.py runserver
Now, in the admin portal, create a new account and notice that his sharenumber is negative (-0 since it's a locked thresholdless account). This means that it will need to be updated once the store is unlocked. To see how this happens try to log in and out with different admin accounts until the context is unlocked; around three log ins should suffice. Try logging out in the admin portal and log in with these accounts:
- django (password django)
- python (password python)
After you have successfully unlocked the store, you can verify that the sharenumber for the account has been set to a positive value and their hash has been updated.