kixxauth / dcube Goto Github PK

Currently queries query on all the data in the datastore, returning matched results from databases other than the one the user is authenticated for. THIS IS BAD. FIX IT.

Each request should result in a single log entry of standard format for data mining in the future

Databases my be setup with a users access list, or may be open to all users.

Databases with an access list need to be able to limit access to get, delete, and update functionality to users on the list.

Entities will simply be data blobs that are explicitly indexed by the index terms provided by the client.

Each group has a level number associated with it which is used to restrict the ability of users to edit other user accounts.

For example, if the level for the databases group is 30 and the level of the admin group is 50, then members of the admin group may edit members of the databases group, but the reciprocal is not true.

This should be implemented in the combination of the 'gate' and 'factory' modules.

When running testrunner.py on the remote server, if the version number cannot be found we get a nasty looking error message:
Traceback (most recent call last):
File "./testrunner.py", line 161, in
main()
File "./testrunner.py", line 119, in main
temp_test_admin, passkey = authenticate(host)
File "./testrunner.py", line 79, in authenticate
auth, username_, nonce, nextnonce = make_auth_request(host, username)
File "./testrunner.py", line 47, in make_auth_request
'Unexpected HTTP status code (%d) on login.'% response.status
AssertionError: Unexpected HTTP status code (404) on login.

The problem seems to come from here:
http://github.com/kixxauth/DCube/blob/master/test/testrunner.py#L46

Maybe we can default to the latest running default version instead of using the version in app.yaml if it does not exist?

If a 'get' query is made the results look like this:
self.assertEqual(ent1['action'], 'get')
self.assertEqual(ent1['status'], 200)
self.assertEqual(ent1['key'], 'foo@1')
self.assertEqual(ent1['entity'], '1')
self.assertEqual(ent1['indexes'], {'idx':'one','class':'$trings'})

When the same entity is returned in a query, it looks like this:
r3 = {
'class':'$trings', 'key':'foo@1',
'entity':'1', 'idx':'one'
}

The first way (the 'get' way) is better.

http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35302

Allow network clients to remove a user with the JSONRequest protocol.

This feature should integrate with CHAP as well.

This user group can only be added manually by Google users with access to the GAE dashboard.

Currently any DCube 'get' call to a /users/ url returns limited use data with a 200 response code. This seems inconsistent and should be changed to a 401 response code for unauthenticated requests and a 200 only for the authenticated requests.

Currently when a response is sent with a 404 or 501 (and maybe others?) DCube status code, it is not sent with credential challenges (nonce, nextnonce in {"head": {"authorization"}}).

This seems to be inconsistent with the DCube protocol of always performing a CHAP authentication whenever possible.

These users can be created by the "sys-admin", "user-admin", and "account-admin" users.

The case where each of these operations would be denied can be added to the automated testing suite.

Thoroughly testing these operations will take some additional trickery and is a separate issue.

In the current state of affairs a put to a user URL that fails simply results in a 403 with no explanation.

For the purpose of developing a client, some more info in the head message would be helpful.

I suppose most large organizations draft a protocol before they start implementing it, but this is not a large organization, and we don't muck about in paperwork. We just fucking do it.

If an already existing user creates a new user, we do not want to return the new user credentials in the response. Instead, the credentials for the existing user that created the new user should be returned.

http://github.com/kixxauth/DCube/blob/master/gae_py/handler.py#L699-706

The database-admin can declare if a database is open or restricted. If it is restricted, then users must be invited by the database-admin, or must request to join and be given permission by the database admin.

There are 3 access lists:
owner: level 100
manager: level 90
user: level 80

Members of the owner ACL may manage the owner, manager, and user ACL.
Members of the manager ACL may manage the the user ACL only
Members of the user ACL are not able to update any other ACL

Run tests of all levels of users against all levels of ACL

Provide RPC to create and delete databases.

Only users in the "databases" group have this capability.

Building on the idea of the permission system in Unix file systems, I'd like to see a user management system for this DCube host that implements a tiered structure of user accounts.

The root user would be anyone with admin access to the Google App Engine account. The next layer would be the system admins with access to just about all of the data that the implementers choose to expose to them through the code. After that would be user managers that could create new data realms and change user permissions.

Basically each layer added would have less and less privileges and the domain of access given to each layer would be determined by the user groups they are a member of.

To help control user management and data security issues I think we need to abstract out a logical layer or module of the program to handle access to data in a similar way to the way Unix systems handle access to disk drives. While it is not like that high level Python code will be able to enforce anything, by abstracting data access out into access control module(s) we should be able to prevent the coding mud pie that will lead to problems with leaking stuff we don't want to leak.

Allow network clients to create a new user with a JSONRequest API.

This feature should integrate with our advanced Challenge Response Authentication Protocol (CHAP).

I'm trying to move the structure of this program towards the functional programming paradigm, but to do this I need to implement a solid data type system within the program.