Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread EWB Server and multiple Databases
Fri, Dec 6 2013 12:50 PMPermanent Link

Glenn McEowen

Using the EWB Server we are hoping to run up to 50 separate clients each having its own unique Database.

Should I:
1) Run a separate "named" server for each client?
2) Or run one server and uniquely name each Dataset in each Database for all 50 clients?
3) Or run one server and use the Database.BaseURL property to point to each client's unique Database? (I haven't been able to make that work yet.)  
4) Or have I missed the whole concept?

Thanks for your help on this.
Sat, Dec 7 2013 7:51 AMPermanent Link

Uli Becker

Glenn,

> Using the EWB Server we are hoping to run up to 50 separate clients each having its own unique Database.

I can't say how to realize that with EWB Server; I wrote my own server,
so I can pass the database in the DatasetName property of TDataset, e.g.
"MyDatabase.MyTablename".
The server splits that and switches to the matching database.

Uli
Sat, Dec 7 2013 10:23 AMPermanent Link

Matthew Jones

Uli Becker <johnmuller54@googlemail.com> wrote:
> Glenn,
>
>> Using the EWB Server we are hoping to run up to 50 separate clients each
>> having its own unique Database.
>
> I can't say how to realize that with EWB Server; I wrote my own server,
> so I can pass the database in the DatasetName property of TDataset, e.g.
> "MyDatabase.MyTablename".
> The server splits that and switches to the matching database.
>
> Uli

Surely the important thing is that the user must be authenticated, and the
server then internally know which database to connect to. The client EWB
code should never be the one to specify the database details to the server,
otherwise it is dead easy to hack. Basically, for any internet based
system, or multi-user system where security matters, the server must be
smart and authenticate.


--
Matthew Jones
Sat, Dec 7 2013 1:20 PMPermanent Link

Uli Becker

Matthew,


> Surely the important thing is that the user must be authenticated, and the
> server then internally know which database to connect to.

Sure, but that can be done by a Login and a sessionID e.g.

> The client EWB
> code should never be the one to specify the database details to the server,
> otherwise it is dead easy to hack.

If you use "Database.load(MyDataset)" you are sending the DatasetName
anyway, aren't you? So I don't see a security issue when sending the
name of the database as well.

Uli
Mon, Dec 9 2013 5:27 PMPermanent Link

Glenn McEowen

Thank you, guys, for your suggestions.

Matthew, you are right about the secure login issues. Though I have considered the need for secure logins, it is still undeveloped. You mentioned "...and the server then internally knows which database to connect to." Does that occur in EWB's Server?

Uli, I was considering the use of "MyDatabase.MyTableName" and changing "MyTableName" from a lookup table based on the client login. While the EWB javascript can handle modified DataSet names easily enough, every "MyTableName" variation would require a unique dataset in the EWB server. 50 clients with 6 tables each would require 300 in the Server's Dataset Manager. While I'm sure the EWB server can handle it, I'm not sure I can.

I thought the "Database.BaseURL" would point to a folder (virtual and secure, of course), but it doesn't seem to work that way. (I probably don't have the concept right just yet.)

In any case, thanks again!
Mon, Dec 9 2013 6:05 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Glenn,

<< 1) Run a separate "named" server for each client? >>

I wouldn't recommend this.  The DNS management, alone, would be a real pain.

<< 2) Or run one server and uniquely name each Dataset in each Database for
all 50 clients? >>

That's not necessary, either.

<< 3) Or run one server and use the Database.BaseURL property to point to
each client's unique Database? (I haven't been able to make that work yet.)
>>

Yes, this.  Except you won't be pointing to a database exactly, rather
you'll just be identifying the client via the first portion of the URL.
However, the actual workhorse in this case will end up being a custom
dataset module running on the single EWB Web Server.  Only with a custom
dataset module can you parse out the URLs as necessary and perform the
authentication, etc. that you need to perform before serving up or consuming
any JSON from the client application.

You can find out more on custom dataset modules here:

http://www.elevatesoft.com/manual?action=viewtopic&id=ewb1&topic=Modules
http://www.elevatesoft.com/manual?action=viewtopic&id=ewb1mod&product=rsdelphi&version=XE&topic=Custom_DataSet_Modules

As mentioned in the links above, there is an example custom dataset module
that is installed with Elevate Web Builder called "DataSetModule" that shows
you how this URL handling works.  The example uses a TClientDataSet instance
as an example of accessing a "different" type of data source, but you can
also easily use any standard database in the same way.  The EWB TDatabase
UserName and Password properties, if assigned in the client application,
will come over as:

X-EWBUser
X-EWBPassword

request parameters, and you can use them to authenticate the user before
sending out any JSON or consuming any JSON for transactions.  Also, be sure
to use an SSL connection (https) if you want to be sure that the credentials
(as well as the data) cannot be intercepted or snooped on in-transit.   The
EWB Web Server does not support SSL connections natively, but you can use
STunnel to do so very easily:

https://www.stunnel.org/

One final note: the URL handling will be changing slightly in the upcoming
1.03 and this will be a breaking change.  The dataset name in 1.02 and
earlier is included as part of the URL, whereas in 1.03 and higher it will
be a URL parameter.  This makes the URL management easier and allows us to
better support scripting URLs like PHP that have file extensions for the
dataset manager.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Dec 11 2013 12:14 PMPermanent Link

Glenn McEowen

Thanks, Tim.

Looks like I have some new "territory" to master, but if it wasn't fun, I wouldn't be doing this.
Image