- globalScope> Global _CALL (_class, _iface, method,...)
- actually i use gcc feature ## for variadoc... think about a way to make this standard.
- globalScope> Global applicationCreateUser (Application this, Credential cred, User user)
- error handling is missing here
- globalScope> Global applicationCreateUser (Application this, Credential cred, User user)
- error handling is missing here
- globalScope> Global applicationCtor (void *_this, va_list *params)
- for both of these...each user should be identified by a number...that way I could use that number in the passwords db and no direct association between email and password could be made when someone get the hands on the password database.
- globalScope> Global applicationLogin (Application this, Credential credential, Session session)
- Handle error...if this fails we have most likely a collision.
- globalScope> Global applicationLogin (Application this, Credential credential, Session session)
- Handle error...if this fails we have most likely a collision.
- globalScope> Global authLdapAuthenticate (void *_this, Credential cred, Uuid user_index)
here we need to get and return the user id
do error logging instead.
- globalScope> Global CLASS (Role)
- We need a good way to serialize a hash. If I can't find any I should choose a different data structure here...but I think there is a way. And as there is none I will change this to simple arrays and add an index to them that is a hash. The arrays could even be static. When a role is load the index on permissions and users is updated each time. The longer I think about it the less I think this role based approach is good... Each user is able to create resources (tasks, projects, etc.) but in the first place these should only be accessible for her/him. Then he should be able to allow other users or groups of users to access these but with each of these separately. So at least this can't be accomplished only with roles or else a role has to be created for every resource. OK, lets think about some roles:
- owner (for each resorce ... this will enable us to share ownership.)
- viewer (for each resource ... these might only see the resource.)
- projectmember (for each project resource)
- teamlead (might have special rights for some projects and be able to see what each projectmember can see)
- projectowner (well ... this might be owner of a project resource)
- projectadmin (being able to change parts of the project but can't see everything...)
- globalScope> Global CLASS (Queue)
- next and first always have to be the same...so get rid of first.
- globalScope> Global hash_pw (const char *, const size_t, unsigned char *, unsigned char **)
- In future this should use a more general purpose hash function, which then will be in utils/hash.c
- globalScope> Global hash_pw (const char *, const size_t, unsigned char *, unsigned char **)
- In future this should use a more general purpose hash function, which then will be in utils/hash.c
- globalScope> Global httpHeaderHandleDouble (void *_this, void *_double)
- do dome error logging...or change to HEAP
- globalScope> Global httpParserPostVars (HttpParser)
- this is very similar to other pair parsing things... key1=val1<delim>key2=val2<delim>...keyn=valn Generalize this!!!!
- globalScope> Global httpParserPostVars (HttpParser)
- this is very similar to other pair parsing things... key1=val1<delim>key2=val2<delim>...keyn=valn Generalize this!!!!
- globalScope> Global httpRequestCtor (void *_this, va_list *params)
- looks like path is not used at all
- File indexable.h
- Maybe merge hashable and indexable. Thus we might get an easy way to exchange the hashing mechanism used for my associative arrays.
- globalScope> Global INSTANCE (class, name)
- this macro requires to close the initializer with an extra curly brancket. This is not nice...find a way to prevent this.
- File queue.h
- change this to a real queue.
- globalScope> Global routerRoute (Router, HttpRequest, Session)
now get all arguments if we have some
somewhere here or above access control have to take place Default policy should be deny, anyway, there are a few resource that should be accessible even when not logged in...the are at least most of the assets as well as functions like version or sessinfo and in fact currentuse to have a way to find out that one is not logged in. In general a deny will be handled by storing an error message in some stash and then trigger a redirect to the login page. To be really rbac it seems neccessary to me to create a user "not logged in" and assign him the exceptions to the default deny policy. For the moment I assume that if there is no resource for the URL in the application it must be an asset and just return NULL indication that we still have no response for the request. Another thought... resources will be created dynamically by creating tasks or users or anything. Each of these resources may have options to admin them. This means most of the time to be able to modify them but additionally the creater of the resource might need the right to modify the rbac rules that apply to that resource. So, if I keep the real resources and their rbac configuration separated as planned it might be neccessary to give the creater of a resource the ability to modify both.
add logging...maybe.
- globalScope> Global routerRoute (Router, HttpRequest, Session)
now get all arguments if we have some
somewhere here or above access control have to take place Default policy should be deny, anyway, there are a few resource that should be accessible even when not logged in...the are at least most of the assets as well as functions like version or sessinfo and in fact currentuse to have a way to find out that one is not logged in. In general a deny will be handled by storing an error message in some stash and then trigger a redirect to the login page. To be really rbac it seems neccessary to me to create a user "not logged in" and assign him the exceptions to the default deny policy. For the moment I assume that if there is no resource for the URL in the application it must be an asset and just return NULL indication that we still have no response for the request. Another thought... resources will be created dynamically by creating tasks or users or anything. Each of these resources may have options to admin them. This means most of the time to be able to modify them but additionally the creater of the resource might need the right to modify the rbac rules that apply to that resource. So, if I keep the real resources and their rbac configuration separated as planned it might be neccessary to give the creater of a resource the ability to modify both.
add logging...maybe.
- globalScope> Global serverCtor (void *_this, va_list *params)
- some logging would be appropriate :)
- globalScope> Global socketCtor (void *_this, va_list *params)
- make this configurable
- globalScope> Global streamWrite (Stream this, void *buf, size_t count)
- I got a segfault in this call under unclear circumstances. Most likely it has to do with a write on a closed connection.
- globalScope> Global streamWrite (Stream this, void *buf, size_t count)
- I got a segfault in this call under unclear circumstances. Most likely it has to do with a write on a closed connection.