I just want to verify that HTTPs works.

We will want to use a secure channel when we move to production since we’re transmitting username, password, client password and other sensitive information.

The ability to delete a PDS via a web driven interface.
-- Users need full control over their data. This includes being able to completely delete their PDS. If they are a member of a shared PDS then only their data should be deleted.
-- Deleting a PDS should remove all traces of the PDS from the Registry Server.

Any user can access the various account pages by navigating to "/account/profiles".

From there the user can create an admin user (and all created users are currently automatically created as superusers #8).

In apps.base.views.is_pds_up, there's a hard-coded value for a discovery url in the PDS, which unfortunately doesn't have that url defined.

Since these are two separate projects, should this be a setting instead of a hard-coded value?

Should be removed.

It isn't going to be possible for us to create a PDS manually for each user.

Imagine having thousands of users register. You can register as a viewer of someone else's data or as a user with your own PDS.

The check boxes don't change this status.

Currently the only way to remove the access is to log into Django Admin and deselect the boxes in each user's page under Auth -> Users.

A web driven status page:
-- This must be accessible from a mobile device.
-- The owner of the PDS should have the ability to revoke the access of any authorized user or application.
-- A list of authorized applications and users.
-- -- The scope of each application should be visible on the page.
-- -- This needs to include a description of the permissions (data type).
-- A list of pending authorization requests from applications and users.
-- -- This page should include a list of applications or users requesting access.
-- A list of the data in the PDS.

VetGuard and Cogito Enterprise are now listed as clients, but I believe they should be applications.

-- We need a web interface for applications (see details in Registry Server section).
-- Given a list of scopes, the data an application has access to must be available via query.
-- All applications must first register with Registry Server through the web interface before they can be given access tokens.

I see how the system currently works with connectors, but I think we need a different back end.

We don't really need the data to be queryable directly from the PDS.

It would be better to have the PDS be a mongo datastore that simply stores the uploaded files instead of aggregating all the data from all the uploaded files into the PDS.

The ability to register via the web or via mobile through a mobile friendly web site.
-- During registration users should be assigned a UUID.
-- During registration users should be able to choose whether or not they want a PDS.
-- Users should then choose whether they want their PDS to be hosted by Cogito or by an alternative solution.

We need the ability to revoke access tokens

By default, the django development server will serve all static files (images, js, css) at /static/. Unfortunately, The ^static$ url in app.base.urls conflicts with this, and anyone trying to get the registryServer running in a development environment will have troubles.

Is the related view app.base.views.static even used anywhere? The comment a few lines above this makes me think this might be cruft.

Would it be safe to remove this code?

I've recently pulled down this project and attempted to get it (with openPDS) running. A couple of things struck me as surprising and/or unexpected:

• It's unusual for a django project to be distributed (i.e. with a whole settings.py file, ). Typically I'd expect a django app or a collection of apps.
• There's a number of discrepancies between the instructions in the top-level README (which work) vs the information in doc/INSTALL.rst. Also, the additional fabfile.py and bootstrap.sh in the root seem either out of date or out of place (again, these are project-level things I'd not expect to see distributed in a reusable app).
• Your installation instructions tightly couple the project with a virtualenv. These two things should be separated. I should be able to completely remove a virtualenv (or switch to another one) completely separate from my django project.
• There appear to be no unit tests at all (perhaps that should be a separate issue).

A few things I'd typically expect from a reusable django app are:

• Documentation for any app-specific settings (not a settings file)
• A requirements.txt in the root of the project. Yours seems to be buried with some deployment-related config files (again something I wouldn't expect here, since I may choose to deploy my project differently).
• A setuptools-compatible setup.py that allowed me to install with: pip install openPDS-RegistryServer
• Some level of tests, runnable with: python manage.py test registryServer

If the goal of this project is to be something that fits within the django ecosystem, the barrier to usage and contributions would be lower if it followed some of the typical community conventions. Some of this information is now available in the django docs, as well.

I hope this is helpful feedback!

When you're editing access tokens instead of listing the name of the client it says "Client object".

The same thing happens with the scope: "AccessRange object".

Develop activity level answer based on the collected WiFi access points.

The funf_write scope is currently the only scope and it's hardcoded into both the Registry Server and the PDS

We need a way to create and edit scopes

-- Every application needs a scope.
-- Applications need different scopes for different data or permissions.
-- Each datum in a PDS should know the list of scopes that have permission to interact with it.

Hi,

I am working on a project using OpenPDS but i think i am unable to set it up on my laptop for development. I am getting following error when i try to setup registry server on my machine.

nika@nika ~/Study/Projects/SnP/registryEnv/openPDS-RegistryServer/registryServer $ python manage.py syncdb
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 443, in execute_from_command_line
    utility.execute()
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 382, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(*args, **options)
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle
    return self.handle_noargs(**options)
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 57, in handle_noargs
    cursor = connection.cursor()
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/db/backends/__init__.py", line 308, in cursor
    cursor = util.CursorWrapper(self._cursor(), self)
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 288, in _cursor
    self._sqlite_create_connection()
  File "/home/nika/Study/Projects/SnP/registryEnv/local/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 278, in _sqlite_create_connection
    self.connection = Database.connect(**kwargs)
sqlite3.OperationalError: unable to open database file

Any help ??

The connector should be provided by the application.

Connectors utilize different scopes.

Connectors store data with the appropriate meta data.
i.e. VG is an application that has the scope vg_raw_data_write.
-- The connector posts any files uploaded by VG which includes multiple data types.
-- The connector adds the appropriate meta data.