ESynCrypto and server method problems with empty body

hnb · 2016-03-18 21:12:25

Hi,

In my case exist 1 server and 6 clients for personnel (so no big challenge for mORMot):

Client - FPC Android ARM6 HF (hcSynShaAes for TSQLHttpClientWinSock)
Server - Delphi XE2 on Windows Server 2012 (my custom TSQLRestServerDB) .

Both problems below are quite rare (1-30 times per day), and the second issue is easy to catch.

Issue 1
I found strange server behavior. When error is raised by DecryptPKCS7 the broken/invalid content is passed to server method :\ (405 is raised by my method for invalid client version and it should never happen, that is probably because broken content generated by DecryptPKCS7 or something like that).

I can't provide any content as example to generate these error, because it is log from real world app.

20160318 19582317  $ EXC   ESynCrypto {"Message":"TAESCFB.DecryptPKCS7: Invalid content"} at 004C8553  stack trace API 004BEE86 00408830 
20160318 19582317  $  +    mormot.server.*****.TSQL*****Server(01DE1DE0).URI(POST root/SyncRequest inlen=272)
20160318 19582317  $ call  	mormot.server.*****.TSQL*****Server(01DE1DE0) SyncRequest 
20160318 19582317  $ debug 	mormot.server.*****.TSQL*****Server(01DE1DE0) TSQLRestRoutingREST.Error: {  "errorCode":405,  "errorText":"Method Not Allowed"  }
20160318 19582317  $ srvr  	mormot.server.*****.TSQL*****Server(01DE1DE0)   POST root/SyncRequest SOA-Method -> 405 with outlen=56 in 46 us
20160318 19582317  $  -    00.000.059

Issue 2
Another disturbing scenario. With heavy traffic (I mean the traffic in restaurant with - many customers with phones and with many actions in app by personnel - for example dinner time) where is dedicated WiFi for clients and dedicated protected WiFi for personnel (and for our mORMot client/server), occasionally I got request with empty body (!).

20160318 18225510  $  +    mormot.server.*****.TSQL*****Server(01DE1DE0).URI(POST root/SyncRequest inlen=0)

There is no way to pass empty body for SyncRequest from client side, the only place where it is called (once per second):

        with TAutoFree.One(LRequest, FContext.SyncRequest) do // create class TSQLSyncRequest
        if LRequest <> nil then
        begin
          LValue := ObjectToJSON(LRequest);
          LCodeError := GClient.CallBack(mPOST, 'SyncRequest', LValue, LResult);
          ResetLastRequest.Lock; {...}

I have few theory:

1. disturbances wifi? Is possible to lose/corrupt some data during transfer? there is TCP so it is unlikely...
2. bug in hcSynShaAes? ...
3. maybe I use badly TSQLHttpClientWinSock ? mhm.

hnb · 2016-03-24 08:32:51

Solved! Note for others:

all mentioned issues are related to TSQLHttpClientWinSock. Was used single instance for 2 threads (GUI thread and synchronization thread, without any lock...). In GUI was used ServerTimeStampSynchronize, in synchronization thread was used CallBack (both methods called from single instance of TSQLHttpClientWinSock).

I think information about not thread-safe TSQLHttpClientWinSock should be more visible in main documentation ( 11.4.3. HTTP client(s) )

Last edited by hnb (2016-03-24 09:34:06)

ab · 2016-03-24 09:48:35

It is not very clear what the multi-thread issue is.
I guess the instance initialization (ServerTimeStampSynchronize) should be done once.
I do not understand what your threads do with the client.

There is a lock/mutex in TSQLHttpClientGeneric.InternalURI to protect the request execution itself.
This mutex is defined at TSQLRestClientURI parent level.
And also used by TSQLHttpClientWinSock.InternalCheckOpen.

hnb · 2016-03-24 10:03:09

ServerTimeStampSynchronize is used for ping purpose. I checked again: there is also few ORM operations in GUI thread. Somehow ServerTimeStampSynchronize (or ORM operations) interacts with CallBack, anyway as is stated in documentation:

note that, in its current implementation, this class is not thread-safe: you need either to lock its access via a critical section, or initialize one client instance per thread

since I use client instance per thread all works perfect - none of ESynCrypto and none of requests with empty body.

hnb · 2016-03-24 13:49:41

URI POST with empty body is still possible :\ for TSQLHttpClientWinSock. I need to prepare some special client version and better log. Looks like we have another bug like fixed in mORMot 1.18.1836 for TCrtSocket/THttpClientSocket ...

hnb · 2016-04-06 11:23:55

Another note to check: maybe error is caused because for FPC:

SockString = type AnsiString(CP_UTF8);

implicit conversion, somewhere...

Last edited by hnb (2016-04-06 11:24:34)

AOG · 2016-04-06 12:11:24

@hnb
IMHO, it would be better to do

SockString = type RawByteString;

with current FPC trunk.
See: http://synopse.info/forum/viewtopic.php … 840#p19840

hnb · 2016-04-06 12:54:18

@AOG that is the part of mORMot, so I think that only ab is able to do that change . I'd like to omit usage of fossil without ab knowledge .

Last edited by hnb (2016-04-06 13:19:25)

mORMot Open Source

#1 2016-03-18 21:12:25

ESynCrypto and server method problems with empty body

#2 2016-03-24 08:32:51

Re: ESynCrypto and server method problems with empty body

#3 2016-03-24 09:48:35

Re: ESynCrypto and server method problems with empty body

#4 2016-03-24 10:03:09

Re: ESynCrypto and server method problems with empty body

#5 2016-03-24 13:49:41

Re: ESynCrypto and server method problems with empty body

#6 2016-04-06 11:23:55

Re: ESynCrypto and server method problems with empty body

#7 2016-04-06 12:11:24

Re: ESynCrypto and server method problems with empty body

#8 2016-04-06 12:54:18

Re: ESynCrypto and server method problems with empty body

Board footer