On Aug 10, 3:25 am, Benigno <bca...@albendas.com> wrote:
> Massimo,
>
> Thank you for your answer. Before moving on, let me try to give a
> quick example of a table:
>
> db.define_table('resources',
> Field('name',label=T('name')),
> Field('company',db.company,label=T('category')),
> Field('department',db.department,label=T('department')),
> Field('long_description','text',default='',label=T('long
> description')),
> ...
> )
> So for example a power user would have access to all the records
> from his company, and a "normal" user, to any record from the
> departments to which he may have access.
>
> Now, I had discarded the decorator method, because, if I had correctly
> understood it, I would need to add the permission of any single record
> addition in that table to any group that should give access to that
> new record. And in any case I would need to add an extra table for
> storing access definitions of the sort of: group_id, table_name,
> table_field_name, table_field_value (group_id, resources, department,
> 'IT') and then check them after every update or insert to the table.
> So I figured that would be too much inserting into permissions.
>
> Also, the nice thing about that would have been using the
> accessible_query, but as it says there... well, cant be used with GAE.
> And in CRUD the SELECT def, does not filter per accessible fields, so
> the only real automated function that I would get would be the checks
> for update and read single records.
>
> def accessible_query(self, name, table, user_id=None):
> """
> returns a query with all accessible records for user_id or
> the current logged in user
> this method does not work on GAE because uses JOIN and IN
>
> example::
>
> db(accessible_query('read', db.mytable)).select
> (db.mytable.ALL)
>
> """
> I do not know though If I have missunderstood or missed something
> about this method.
>
> The second option seems nicer, basically if I understand what you
> mean, it is dinamically creating an extra clause in all queries.
> Right?. Is that sintax correct?
everything you say is correct.
> can I put subqueries as you mention?
> return db(query)(subquery)(....)
Yes this is the right syntax and if both query and suquery involved a
single table should work on GAE.
>
> I am in any case a bit afraid of GAE, I think I am ok, as these would
> be all equalities and no inequalities are added on this part, (I think
> GAE only lets you have one field with inequalities). But I am no
> expert, and I am not sure I might screw it up by a bad table and auth
> design.
>
> As a side question. On a table such as the one shown up there, the
> requires.IS_NOT_IN_DB() that would be needed, would need to check on 3
> fields (that is, I dont want the same combination of Company/
> Department/Name to happen how would that correctly be done? does that
> translate correctly to GAE?
Yes it should work on GAE for most queries as long as they involved a
single table.
> Thanks for your help,
> Benigno.
>
> On 10 ago, 08:52, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > The decorators
>
> > @auth.requires_login()
> > @auth.requires_membership('group')
> > @auth.requires_permission('type','table'record_id')
>
> > work on any function, work on gae and are efficient.
>
> > You mail also want to build functions like
>
> > def record(query):
> > if auth.has_permission(...):
> > return db(query).select(....)
> > else:
> > return db(query)(subquery)(....)
> > Hope this helps.
>
> > On Aug 9, 4:28 pm, Benigno <bca...@albendas.com> wrote:
>
> > > Hello,
> > > I'd like to pose a question, that is probably quite basic, but I do
> > > not see any way to do it right (by right meaning something that
> > > doesn't take too many queries, processor, ram or looks really nasty on
> > > the code).
>
> > > So, I would like to know what is the best way to set up an
> > > authorisation process that filters data by different fields depending
> > > on the authorisation of the given user. On its most basic form,
> > > imagine that I am setting up a service app, that allows different
> > > companies to sign in and pay for a number of users. Those users
> > > grouped by department.
>
> > > I would like that they are able to set up the access rights for each
> > > of those users, so that once they set a user with accesss to a certain
> > > department (or several departments), anything he does is filtered for
> > > those he has access only (this may span any number of tables in which
> > > data may be company/department specific). Of course this for many
> > > different companies.
>
> > > The second part of my question is: What would be the best way to set
> > > it up so that it works nicelly in GAE?.
>
> > > Thanks in advance,
> > > Benigno.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
