On Sun, 2011-12-04 at 17:59 +0100, Andreas wrote:
> Am 03.12.2011 23:54, schrieb Tamara Temple:
> > If you give every application user a unique set of database access
> > permissions, that means that any one of those users can access your
> > data base WITHOUT going through your application if t
On 4 Dec 2011, at 16:59, Andreas wrote:
> Am 03.12.2011 23:54, schrieb Tamara Temple:
>> If you give every application user a unique set of database access
>> permissions, that means that any one of those users can access your data
>> base WITHOUT going through your application if they manage to
Am 03.12.2011 23:54, schrieb Tamara Temple:
If you give every application user a unique set of database access
permissions, that means that any one of those users can access your
data base WITHOUT going through your application if they manage to get
access to your data base server. Is that clea
To put it another way - your appl should control the access that a user
has - different screens/functions available depending upon the signon
credentials. The entire application's sql use (or all 'users' of the
database) should have a minimal number of user ids associated with it - both
to mak
Andreas wrote:
> Am 29.11.2011 23:54, schrieb Tamara Temple:
> > As I read it, the OP may be confusing application user logins and
> > the credentials used by the application to access the data
> > base. Individual application users should *NOT* have access directly
> > to the data base by having
On 3 Dec 2011, at 16:46, Andreas wrote:
> Am 29.11.2011 23:54, schrieb Tamara Temple:
>> As I read it, the OP may be confusing application user logins and the
>> credentials used by the application to access the data base. Individual
>> application users should *NOT* have access directly to the
Am 29.11.2011 23:54, schrieb Tamara Temple:
As I read it, the OP may be confusing application user logins and the
credentials used by the application to access the data base.
Individual application users should *NOT* have access directly to the
data base by having their individual credentials i
Jim Lucas wrote:
> On 11/29/2011 6:28 AM, Al wrote:
> > On 11/29/2011 7:40 AM, Nilesh Govindarajan wrote:
> >> On Tue 29 Nov 2011 01:34:08 PM IST, Andreas wrote:
> >>> Hi,
> >>>
> >>> is there a most advisable way to store db-passwords of an open
> >>> user-session?
> >>> As far as I get it, a com
On 11/29/2011 6:28 AM, Al wrote:
>
>
> On 11/29/2011 7:40 AM, Nilesh Govindarajan wrote:
>> On Tue 29 Nov 2011 01:34:08 PM IST, Andreas wrote:
>>> Hi,
>>>
>>> is there a most advisable way to store db-passwords of an open
>>> user-session?
>>> As far as I get it, a common login strategy is to let
On 11/29/2011 7:40 AM, Nilesh Govindarajan wrote:
On Tue 29 Nov 2011 01:34:08 PM IST, Andreas wrote:
Hi,
is threre a most advisble way to store db-passwords of an open
user-session?
As far as I get it, a common login strategy is to let the user login
by name&password, check it, store a login=
On Tue 29 Nov 2011 01:34:08 PM IST, Andreas wrote:
> Hi,
>
> is threre a most advisble way to store db-passwords of an open
> user-session?
> As far as I get it, a common login strategy is to let the user login
> by name&password, check it, store a login=TRUE as php-session variable
> and later use
Hi,
is threre a most advisble way to store db-passwords of an open user-session?
As far as I get it, a common login strategy is to let the user login by
name&password, check it, store a login=TRUE as php-session variable and
later use a common dbuser+pw to query data provided "login" is TRUE.
12 matches
Mail list logo
