gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnue-dev] Appserver/Common Issues


From: Reinhard Mueller
Subject: Re: [Gnue-dev] Appserver/Common Issues
Date: 23 Nov 2002 15:05:25 +0100

Stan,

Am Fre, 2002-11-22 um 19.00 schrieb Stanley A. Klein:
> >Consider we have the "final" GNUe Application, where we have about 20
> >forms and 50 reports showing the purchase price. I install that to a
> >customer and the customer tells me to make purchase prices invisible to
> >certain users. So i would have to change 20 GFD's and 50 GRD's.
> >The next update then would probably break it again.
> 
> I see the issue you are raising.  I took it to use as one of the examples
> in the document I'm writing (which I hope to finish the current revision of
> soon).  :-)
> 
> If the number of gfd's and grd's is limited, the strategy I described would
> work.  For a lot of gfd's and grd's you are right that we would need to do
> something else.

Agree.

> I think there are some database systems that provide access control by
> field.  If such a database system is available, I would recommend using it
> to provide control of the price field. The implication for GNUe and
> appserver is that the field would need to be traceable from the client side
> through appserver to the database side.  I don't think that was guaranteed
> in the old GEAS.  I hope it can be provided in appserver.

This could work if Appserver logged into the database using the user's
username. However, our strategy will more probably be Appserver using
it's own logname to log into the database, and therefore having more
access rights to the database than the user would have when accessing
the database directly.

Example: Appserver could automatically (by using bound procedures)
maintain some redundant fields in the database, like total invoice
value. These fields would be read-write for Appserver, but they would be
read-only for user's SQL access.

> Otherwise, the only way to provide the control is to do it by GNUe
> functionality, recognizing (and telling prospective users) that the
> security assurance of such an approach is likely to be less than in other
> approaches.

If we want to remain portable and database independent, we don't have
another choice IMHO than doing access control within Appserver. Whether
this is secure or not only depends on the quality of our own code.

Thanks,
Reinhard

-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]