Re: Anyone using VPD and Forms for security?

Timbo,

I can't talk about option 2 because I don't have any experience with vpd's.
About option 1: you have to avoid that your users connect to the database using
the general oracle usercode with sqlplus or other tools. In your design this general oracle usercode has every privilege on the tables . To avoid this problem use two oracle users: one is the schema owner and the other is the general oracle usercode which every one will use to connect to the database. Define roles with passwords for the different functions. Grant priv's on the schema owner objects to the roles. Give the general oracle usercode only the create session privilege and in your app's you can enable the roles needed by the application user. In your users table add a column: the role they can use. Avoid that people have access to the sources because the roles passwords will be there.

good luck. Kind regards,

Ivan

Timbo wrote:

> Hi,
>
> Using 9iR2 database, app server, developer suite.
>
> We are developing an application that has approx 200 users,
> and will grow. Utilizing Forms and Reports for bulk of
> development. The users have different functions they will
> perform in the system. All inserts/updates will be stamped
> with the user's id.
>
> We are considering 2 security paths:
>
> 1. A user login form that validates off a users table. Once
> validated, the userid and items are placed as global variables
> and referenced by the other forms. No need for individual
> database users, as the user that forms and the app server uses
> to connect to the db will be used. So one user, one db schema.
>
> 2. Virtual Private Database - VPD From the little I understand of
> this, each user of the application will be a database user. This will
> require more maintainance on the db side to have the users access the
> same schema.
>
> My questions are:
>
> What are others doing?
>
> Does VPD integrate with Forms and Reports relatively seamlessly?
>
> Which would be easier to maintain?
>
> Thanks for any guidance.
>
> Tim
Received on Fri Nov 15 2002 - 11:22:12 CST