Rita

> Then you discover its using DBIsam and you can see the remote tables,
> would you be tempted to take a peek ?
> I would most would but would I alter my balance I doubt it. If however
> some compulsive gambler has hit rock bottom and maxed out his cards
> then they would.
> So I guess I should do as Tim suggests and fiddle with the engine.

Another option would be to use something like remote objects/data abstract.
Your server application has the passwords to get to the database and your
client application only has passwords to get to the server application.

John

Hi John thanks for that I have other stuff to
look at too
It would be nice if Tim could add a Session
password to Database part of the server
so registered users logging on could fire or
retrieve it automatic and prying eyes who
get the server ip cant use DBSYS to get in
without the session password. That way
the server would need to be breached.
Back doors you close one another opens.

Rita

Ok Roy thanks.
Rita

Rita,

<< It would be nice if Tim could add a Session password to Database part of
the server so registered users logging on could fire or retrieve it
automatic and prying eyes who get the server ip cant use DBSYS to get in
without the session password. That way the server would need to be breached.
>>

I'm not quite sure I understand what you're proposing here.  The issue is
that DBSYS is just another Delphi application to the server, so if you allow
someone INSERT/UPDATE/DELETE access to a given database on the server, then
you will also be giving them the equivalent access in DBSYS.

ElevateDB gets around this with stored procedures.  You can give someone
Execute privileges for a stored procedure, but not allow them to directly
update the base table.  Stored procedures always execute as a System user,
so the stored procedure can access/update database objects that the user
cannot access directly.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]"  wrote in message
news:A3229F11-C0CB-4165-97E6-C46DEADA741E@news.elevatesoft.com...

Rita,

I'm not quite sure I understand what you're proposing here.


Tim I was suggesting that when the Admin sets up a username and password
to a database on that server and the tables are password protected. Then
when an authorised user logs on the server is savvy enough to allow them in
without prompting for the SESSION password.
That way when someone finds the ip address of the server in the exe they
cant possibly find the session password.
Just a thought.
As it is now the session password needs to be in the users exe and is easy
to see with a hex editor or extract with a disassembler.
As is now I use

   sPW1 := 'Mi';
   sPW2 := 'cr';
   sPW3 := 'os';
   sPW4 := 'of ';
   sPW5 := 't 2010';

  dm.sesHorses.AddPassword(sPW1+sPW2+sPW3+sPW4+sPW5);

That hides the session password from being read as Microsoft 2010
and to retrieve it you need the entry points such as in a disassembler.
Hope you can follow now not many can
Rita

Rita

> It would be nice if Tim could add a Session
> password to Database part of the server
> so registered users logging on could fire or
> retrieve it automatic and prying eyes who
> get the server ip cant use DBSYS to get in
> without the session password. That way
> the server would need to be breached.
> Back doors you close one another opens.

You could quite simply roll your own.  Create a procedure server side which returns the session password(s) as required by the
client app that is running.

John

Rita,

<< Tim I was suggesting that when the Admin sets up a username and password
to a database on that server and the tables are password protected. Then
when an authorised user logs on the server is savvy enough to allow them in
without prompting for the SESSION password. >>

I still don't see how this solves the issue - you'll still have to provide
the table passwords via the client application.

--
Tim Young
Elevate Software
www.elevatesoft.com