I agree wholeheartedly with the idea that any application security should be integrated with LAN security. That was the idea I was trying to get across but I don't think I expressed it as eloquently.

>I don't think it makes sense to have your users login or have admin users add new users and give them rights. The network OS should do this, (and in the case of Oracle, it does too). These resources really know how to autheticate users. Anything that we build is duplicating functionality we already have.
>In database design, we try to put data in just one place. Where is the logical place to put a user list? In a single application? (You are supposed to say no.) Back in the days of DOS, each application had to manage it's own printers, drivers and all. Somewhere along the line, we realized that was an OS function.
>Same with security. Someone must add new users to the Network. They can be assigned groups. The groups and contain other groups. We should have one place to go for adding a user and describing their rights. Your application can know the user through SYS(0). It can know if they are a member of specific groups. They've already logged in to a very secure NT box, why make them go through your app's login?
>I'm not saying you don't need a security object(s). I would envision your security object to be a subclass of the basic rules of your application. Normally when the user attempts to park on a record or set of records, do you have a rules object that answers these questions?
>CanIShow()
>CanIEdit()
>CanIDelete()
>CanIAddNew()
>and if a rule answers no, what is the reason? No user can edit, grant me this example, when a record has been archived. That's an application rule. You might decide no one can delete a parent without deleting the children first. You might decide they cannot add when they are on a new record. These rules have nothing to do with "who is this user and do they have rights", but the methods are all the same as those needed for security.
>
>
>>I was wondering about what most of you do for prompting users to login to your applications, if at all.
>>
>>Do you/your clients generally require this or are your applications usually only distributed to the users who are supposed to have access?
>>
>>Do you interface with the network login and use that to authenticate or do you create a user table for the app itself?
>>
>>When using a back-end DB like Oracle, SQLServer, do you have the app connect in with a dba account and just handle rights and roles within your app?
>>
>>
>>Most of the stuff I've done only required basic security, like rights to screens, running particular reports, tracking who modifed each record, etc. So I've written everything into the app itself. The only issue was being able to see passwords, but I have a basic work around for that. Since most have been desktop apps, they've pretty much stuck to VFP databases and the users needed to get into the tables "behind-the-scenes" anyway.
>>
>>I ask this because now I'm planning on creating a client/server version of one of my apps and would like to know how the experts handle this.
>>
>>
>>Thanks for any comments, ideas, past experiences your willing to share on this.
>>
>>- Brian