mORMot Open Source

Well, since the connected account is Admin and no update to the AccessRights property of the AuthGroup object was made before the Rest db update action, I did a debug on the client side, and found the following:

The TOrmAccessRights record (not an object, indeed), did not preserve the GET, PUT, POST, DELETE arrays between the call of the Edit method and a call of the toString method. To testify this, the following workaround code works fine!

var
  grp: TAuthGroup;
  oar: TOrmAccessRights;
  ars: RawUTF8;
begin
  grp := TAuthGroup.CreateAndFillPrepare(MainForm.RestClient.Orm, 'ID=?', [3]);
  try
    if grp.FillOne then
    begin
      oar := grp.SqlAccessRights;
      oar.Edit(MainForm.RestClient.Model, TStatus, false, true, false, false);
      oar.Edit(MainForm.RestClient.Model, TPerson, false, true, false, false);
      FormatUtf8('%,%,%,%,%', [byte(oar.AllowRemoteExecute),
        GetBitCsv(oar.GET, MAX_TABLES), GetBitCsv(oar.POST, MAX_TABLES),
        GetBitCsv(oar.PUT, MAX_TABLES), GetBitCsv(oar.DELETE, MAX_TABLES)], ars);
      grp.AccessRights := ars;
      MainForm.RestClient.Update(grp);
    end;
  finally
    grp.Free
  end;
end;

That was exactly the meaning of my message @ab. The TAuthUser class has no published property with the plain password and I presume that it is meaningless to apply this validator on the PasswordHasHexa property. So, on which property can we apply this password validator? Can we create a dummy, DTO like class (not a TOrm descendant, or if it is mandatory to be a TOrm child to not include it in the model creation, so to avoid having this table in our DB), with a plain password as published property, then apply this validator on this property and if it succeeds to use this value to assign it to the PasswordPlain property of the TAuthUser class instance?

Not a quite elegant solution...

Thanks Thomas. I need to feed a TOrmTableToGrid object via the FillTable method, i.e. my goal is to fill a TOrmTable object with the TDoctor instances, with the joined objects expanded. If CreateAndFillPrepareJoined method worked as I expected, then it would be very easy, just by calling the FillTable method of the TOrm object. Now I have to find an alternative approach.

Delphi

You're welcome, thank you @ab (and the rest of the mormot contributors) for your outstanding work!

Thanks Thomas!

I confirm that this is a locale related problem. My current locale setting is el_GR.UTF-8. When I run the mormot2tests program inside a container (via DDEV-Local) which by default, has locale C.UTF-8 all tests are passed successfully.

Is it possible to have a locale agnostic static version of quickjs?

Thanks a lot @ttomas for the hint. With this option I can debug the tests project. The failed test is at line 166 of test.core.script unit:

        CheckEqual(Run(
          'add(434.732,343.045)'), '777.777');

The evaluation of the javascript expression gives the following result:

<JSVALUE> = { U = { I32 = 777,  TAG = 65536,  F64 = 1.3906711615708398e-309,  PTR = $1000000000309,  U64 = 281474976711433}}

which is apparently integer and the equality check with the float value '777.777' fails.

Hi

I cloned the mORMot2 repository, downloaded the static files with SQLite 3.35.5, compiled and run the regression tests, using FPC 3.2.0 on OpenSUSE Linux. Unfortunately, some tests failed:

/home/damian/mORMot2/test/fpc/bin/x86_64-linux/mormot2tests 0.0.0.0 (2021-07-07 16:36:50)
Host=XXXX User=damian CPU=4xIntel(R)Core(TM)i5-4460CPU@3.20GHz(x64):FFFBEBBFBFFBFA7FAB270000000000000006009C OS=Suse=Linux-5.3.18-lp152.78-default#1-SMP-Tue-Jun-1-14:53:21-UTC-2021-(556d823) Wow64=0 Freq=1000000
TSynLog 2.0.1 2021-07-07T13:38:23

0000000000000001  ! fail  #5 ../../src/core/mormot.core.test.pas tsyntestcase.testfailed (944) ../../src/core/mormot.core.test.pas tsyntests.run (1171) mormot2tests.dpr main (96) 
00000000000156FF  ! fail  #7 ../../src/core/mormot.core.test.pas tsyntestcase.testfailed (944) ../../src/core/mormot.core.test.pas tsyntests.run (1171) mormot2tests.dpr main (96) 
0000000000016CF9  ! fail  #9 ../../src/core/mormot.core.test.pas tsyntestcase.testfailed (944) ../../src/core/mormot.core.test.pas tsyntests.run (1171) mormot2tests.dpr main (96) 
00000000027A9CFE  ! fail  #6046 777<>777.777 ../../src/core/mormot.core.test.pas tsyntestcase.testfailed (944) test.core.script.pas ttestcorescript.quickjslowlevel (170) ../../src/core/mormot.core.test.pas tsyntests.run (1171) mormot2tests.dpr main (96) 
... (the error above is repeated 1000 times up to #40012)

Any hints?

OK I see. However, I think that the token's renewal in the context of a valid request when it is close to expire is simpler (it acts also as an implicit renewal request), with no need to implement a separate renewal action from the client's side or worse, to put this action inside polling (e.g. like window.setInterval etc.), which is more error-prone  and risks mishandling of idle user. The only consequence is a need for a blacklist (also recommended as a good practice by owasp), which is covered fine by a TSynDictonary property.

I could understand this argument if the token is actually stored in the cookie, but this is not the case here. The hardened cookie is used just to create a path outside javascript scope, so the server can cross check not only the token's signature but also the client's origin (sender). That is I think the reasoning of the OWASP recommendation.

This is suitable for a Delphi client, but in this case I'm talking about a javascript client (e.g. a single page js application). As far as the service receives valid requests I see no reasons to leave the token expire and prompt the web user to enter again the credentials, moreover since the timeout is kept quite short (15 minutes).

The web client's session is between the js web app and the front desk in memory service which by default doesn't handle user's authentication (aHandleUserAuthentication is false). So I presume that any SessionID will be between the front desk service and another mORMot service which maintains the user credentials. It doesn't seem very useful to me to pass this SessionID to the web client.

Thanks @ab for your remarks.

Thanks a lot!

How do you handle user authentication/authorization at this level?

mpv I followed your advice and in line  6897 of SynCrtSock I made the following addition after the else:

  if ContentLength>0 then begin
...
  end else ContentLength := 0;
  if ContentLength<0 then begin // ContentLength=-1 if no Content-Length
...
  end;

And the problem solved! Do you think ab that this change should be applied also in the git repository? Many thanks.

My latest mORMot commit applied is 60aeaba63d770dcad2841aa0fe9e234d1982b51a from Feb 8 if I get it correctly (I'm not experienced with git). The whole installation is on OpenSUSE Linux Leap 15.2. The server is compiled with FPC 3.2.0. There is a reverse proxy indeed, because the client is an HTML page with jQuery, served by nginx hosted in a docker container, configured by ddev. The nginx is configured with TLS/SSL and as a reverse proxy to the mORMot server, located outside the container in the main operating system.

There is a similar behavior with Firefox and Chrome. A plain GET request to timestamp as you suggested takes 1ms to complete. Other CRU db actions to AuthUser using REST are performed rapidly. When I bypass the web server/docker container and load the html page from the filesystem, the delete is performed with no delay, provided that I have included also in the mORMot server compilation the  AccessControlAllowOrigin := '*' setting. The latter is neither necessary in the previous (web hosted) setup, nor affects the delete performance. In conclusion, the delay resides in-between in the nginx reverse proxy, but I can't find out the reason yet.

Thanks a lot ab you are very clear in functional terms, but my problem is how to make the system interpret the enumerated code returned by the interface method to respond with an HTTP_BADREQUEST, together with a json with ErrorCode, ErrorText properties. By just returning the second enumerated value the system responds with an HTTP_OK and the web client interprets this as a normal execution.

My (seemly unorthodox) solution is the following:

1. Inherit the service class from an TInterfacedObjectWithCustomCreate and add a method of TNotifyErrorURI type, where I catch the EServiceExcepton and call Ctx.Error accordingly:

function TBareService.NotifyErrorURI(Ctxt: TSQLRestServerURIContext;
  E: Exception): boolean;
begin
  if E is EServiceException then
  begin
    Ctxt.Error(E.Message);
    Result := false
  end
  else Result := true
end;

2. In the overridden constructor I linked the sever's OnErrorURI event to the aforementioned method:

  inherited Create;
  aServer.OnErrorURI := @NotifyErrorURI;

3. Raise inside the service method an EServiceException according to my error checking logic with a descriptive message to the client.

I would clearly prefer the return of enumerated values but obviously I missed the way to do it, as I explained in my first paragraph.

Ps. This topic is similar to the following old forum topic: https://synopse.info/forum/viewtopic.php?id=4293

I've downloaded release 2.4 (thanks Eugene ) and built and run the Demo in Linux x64 with FPC  3.2.0 / Lazarus 2.0.9. When the application is shutting down (after pressing the Enter key), it raises an access violation exception at line 982 of unit mORMotHttpServer, when it attempts to execute

fDBServers[0].Server.EndCurrentThread(Sender);

This happens also in Windows 10 64 bit with FPC/Lazarus but not with Delphi 10.3.

It might have something to do with the usage of IAutoFree, because using a classic try/finally approach doesn't raise any exception.

I found a solution by passing window.location.hostname. Sorry for my rather silly question.