Skip site navigation (1) Skip section navigation (2)

Re: Client UI, ODBC, PG & permissions

From: Steve Jorgensen <jorgens(at)coho(dot)net>
To: "pgsql-odbc(at)postgresql(dot)org" <pgsql-odbc(at)postgresql(dot)org>
Cc: 'Philippe Lang' <philippe(dot)lang(at)attiksystem(dot)ch>
Subject: Re: Client UI, ODBC, PG & permissions
Date: 2004-03-25 09:13:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
Generally, I use the back-end security and give each user their own copy of 
the front-end, and all the links to tables and views are created with the 
password saved, so the user won't be asked for a logon every time.

You can use any combination of Access and network/filesystem security to 
ensure that each user is the only one with access to their own front-end. 
 For deployment, you can send out the front-end linked with the logon of a 
user with minimum permissions, and have a re-link routine that lets the 
user enter the logon information to be saved with the links.  After 
re-linking views from code, you need to execute DDL queries to create 
virtual primary keys on views so Access can query them efficiently, and so 
it will allow updates via recordsets (e.g. the recordset behind a form). 
 The DDL is in exactly the same format as if you were simply creating a 
normal primary key on a table.

If you need to block access to a particular field, deny the user access to 
the table, and give them access via a view that does not include the field.

On Wednesday, March 24, 2004 11:59 PM, Philippe Lang 
[SMTP:philippe(dot)lang(at)attiksystem(dot)ch] wrote:
> Hello,
> I would be interested in knowing how you deal with permissions in your
> ODBC applications. Mine is based on a thin Access client that accesses
> Postgresql remote tables and stored procedures through ODBC.
> I have already granted permissions to users based on their specific ODBC
> login and password. Depending on the group they are member of, they
> receive either SELECT, INSERT, UPDATE or DELETE rights on the table.
> This works fine.
> Now, the problem is when you have to adapt the UI in order to show the
> user he won't be able to update a form, for example. At the moment, the
> user only know when he tries to commit his changes that he shouldn't
> have tried to. Another problem is when a certain field from a table
> shouldn't be visible to certain users... How to deal with that?
> I have thought of different "home-made" security systems, where I deal
> with users in my database directly, instead of using ONLY the PG
> security.
> How do you manage permissions in your applications? Is it possible to
> read the permissions a user has on a specific table from the client, and
> adapt the UI accordingly?
> Thanks
> Philippe Lang
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

pgsql-odbc by date

Next:From: Nuno Pimenta, Eng.Date: 2004-03-25 10:47:31
Subject: Postgres ODBC error
Previous:From: Philippe LangDate: 2004-03-25 07:59:21
Subject: Client UI, ODBC, PG & permissions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group