What are the cases where you have to take into account the development of a web server module to not operate on ewb client ?

1. The autentication (login password )
2.
3.
4.

apart from the first what do you think ?

Pasquale wrote:

> What are the cases where you have to take into account the
> development of a web server module to not operate on ewb client ?


I am not sure I understand the question. Are you asking what is
sensible for doing on the client, and what on the server? If so, then
that of course depends on the application, but as a general principle
you want to keep the server doing things that you want complete control
over. For example, if the customer is buying things, then the total
amount payable should be calculated on the server, not in the client.
Yes, people have indeed used forms that have the total as a variable
and the server believed it. Buy TV for $500, set hidden amount field to
$1, process order.

Me, I tend to do this a little more than perhaps I might, because I
base my applications on an "interface" where you log in and then can do
certain things like get your order details, initiate actions, etc. The
queries are all done "incidentally" to the function being asked for, so
the client has no idea about any tables etc. Indeed, you don't ever
want to expose tables to the client if they are shared between users of
different organisations. That could give you a big ouch.

These things just take some thinking about, to architect a decent
solution that remains secure, speedy and useful.

--

Matthew Jones

Jones I 'm developing this platform : http://95.226.31.180/payplatform.html

(for access write : test for SUER and test for PASSWORD)

For example every time you go to the AREA OPERATIVA - > RICARICHE ONLINE and purchases a product must be scaled prepaid credit that you see at the top right on the home page .

This it can within the customer then this is wrong ?

On 10/21/2015 7:22 AM, Pasquale wrote:
> What are the cases where you have to take into account the development of a web server module to not operate on ewb client ?
>
> 1. The autentication (login password )

Not necessarily. Basic Dataset authentication is already built-in so you
do not need any modules if you're using basic database authentication
(see "Authenticating Requests" ub
http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=Creating_Loading_DataSets)

You need web server modules if you need to go beyond this - for example
using LDAP or more complex methods for auth like session iD etc.

> 2.
> apart from the first what do you think ?

There "can" be lot of things you can use web server module for once you
go beyond simple dataset model. However there are often other methods to
achieve this as well so you'd need to decide on your app and serevr design :

Things like :

- General server-side business rules (these could in many cases also be
done by database constraints and/or triggers)

- Back-end data validation (i.e. does the data make sense - again can
often be done also with db triggers and such)

- Server side report generation (pdf, etc) (you could achieve similar by
using a reporting server and just host a TBrowser in EWB app and point
to proper URL)

- more generically you can use web server modules to generate a web
server API that you call directly using TServerRequest and move towards
API based approach (vs table approach that TDataset model is)

I have no doubt there are lot more examples.

Raul

Pasquale wrote:

>  and purchases a product must be scaled prepaid credit that you see
> at the top right on the home page .

I don't fully understand the language here, but I get the impression
this is a system where you can purchase things. If this is at all
possible that an end user might access this, then I'd say you need to
move all data management to the server. That probably means not using
the EWB server service, but developing your own (which you can still do
in Delphi). Maybe an EWB module is good enough - I've not dug in deep -
but the act of assigning some product to an account and taking money
off the balance should definitely be server side.

If this was all totally internal, so it is a system administrator who
runs the software, then you can be less strict, but even so, I'd want
to be server side for the transactions.

Basically, think like a criminal. I can easily see data like:
{   "rows": [
{ "ID": 1, "Listino": "BASE", "RagioneSociale": "MERCHANT TEST",
"Indirizzo": "VIA", "Cap": "00000", "Citta": "NESSUNA", "Agente": 1 }
] }
going over the network. Open the Chrome debug items and see what is
being sent. If there is ANYTHING that can be used for inappropriate
purposes, then it shouldn't be there at all.

(I am going to be offline for a few days, so won't be able to respond
for a while.)

--

Matthew Jones

On 10/21/2015 9:01 AM, Pasquale wrote:
> Jones I 'm developing this platform : http://95.226.31.180/payplatform.html
> (for access write : test for SUER and test for PASSWORD)

First of all your login is easily crackable for 2 reasons :

1. you're sending a request with username only

http://95.226.31.180/datasets?method=rows&dataset=PosUtenti&Utente=%27test%27

and then returning user record including their hash !? (which means
you're doing validation on client side - big NO NO).

The issues you have:

1. I can easily write a program that will repeatedly query your web
service with different usernames to discover what users you have.

Do not publish your login info like this - you should send username and
password in the request and response should be either OK/Failed mesage
with no actual data "leaked".

2. Do not validate login on clients side - again - simple local JS
injection attack would allow one to bypass that completely.

3. Do not use MD5 - that is broken (and definitely don't sent it back to
client).

You could go to places like https://crackstation.net/ and put in the
hash from your table "098f6bcd4621d373cade4e832627b4f6" and see what it
comes back with : "test") but since you're not salting your password
simple rainbow table lookup often works.

if you want to has the password (which is a good thing) then it all
needs to happen on server side and none of that data should ever be sent
back to client. Also use SHA-2 and salting.

This is just from login screen as i got an error about "Utente risulta
già collegato !" when i tried to login.

Raul

ok I understand the problem .

But when you say that you have to work on the server side what should I do ?

I have to develop a form with Delphi ? ( so they are forced to buy even delphi ? ) then I must indicate in EWB Web Server ---> Module ?

On 10/21/2015 10:08 AM, Pasquale wrote:
> ok I understand the problem .
> But when you say that you have to work on the server side what should I do ?
> I have to develop a form with Delphi ? ( so they are forced to buy even delphi ? ) then I must indicate in EWB Web Server ---> Module ?

No - you simply cannot use the authentication model you are currently
using (hash computation etc) without server module.

You can use the EWB dataset authentication instead and do not need to
write any web server modules.

See
http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=Creating_Loading_DataSets
for details but general idea is as follows:

- all your dataset requests will require authentication

- you need to use SSL/TLS since you will be sending username/password in
clear text

So your basic operation would be

1. user enter username/password
2. your EWB app caches it internally
3. When you do your dataset operations (LoadRows etc) you include the
username/password
4a. If the request works you get data back (like now)
4b. if request fails you get an error and have to deal with it (you need
to basically deal with authentication errors as well as normal errors
you would get with data )

5. You can implement timeout in EWB app that would clear the cached
username/password and force user to login.


If i were doing this i would query some known table on initial login
screen (for example app version info or such) and if you receive
expected data then you know auth is OK. Otherwise you can put up an
error message with "login failed" like you do now.

Raul

excuse me raul

i have this code

procedure TFormAutenticazione.Button1Click(Sender: TObject);
Var
PasswordMD5 : String;
begin   
 IF (Edit1.Text <>'') And (PasswordEdit1.Text <>'') Then
 Begin
   PasswordMD5 := calcMD5(PasswordEdit1.Text);

   PosUtenti.Params.Clear;
   PosUtenti.Params.Add('Utente=''' + Edit1.Text+'''');
   PosUtenti.Params.Add('Password=''' + PasswordMD5+'''');
   
   DataBase.LoadRows(PosUtenti);
 End;
end;

procedure TFormAutenticazione.PosUtentiAfterLoad(Sender: TObject);
begin
 IF PosUtenti.RowNo = 1 Then
 Begin
     AutenticazioneOK  := True;
     UtenteAutenticato := PosUtenti.columns['Utente'].asString;
     IDMerchant        := PosUtenti.columns['IDMerchant'].asString;
                             
End;
End;


how do I use "Authenticating Requests" ?

write me example please .

tanks.


However beyond authentication to write the web server module need to force Delphi ?

you can use Lazarus that is free ?

Pasquale,

<< However beyond authentication to write the web server module need to force Delphi ? >>

For now, yes.

<< you can use Lazarus that is free ? >>

Not yet, I'm looking into it.

Tim Young
Elevate Software
www.elevatesoft.com