mORMot Open Source

Anyone willing to pick up this proposal?

No answer to this? I thought it was a good idea...

I know that the HTTP Basic authentication is inherently weak, in fact Sabbiolina is forcing it through a TLS channel. Yet it still remains fairly weak for other reasons.

But it's compatible. If mORMot had supported a more secure - yet highly compatible - authentication scheme, like OAuth(2) for instance, we would have gone that way.

mORMot's native auth scheme, with its two-phase challenge, is strong, but it's a pain if you need to create an API to be accessed by apps written in PHP, Python, Ruby, Java, C# (etc...) because no one wants to implement the client-side of mORMot's auth scheme when the languages they use already have very reliable and mature OAuth client libraries they could leverage upon.

On top of that consider when you have zero control over the backend DB, and you have to abide to restrictions (no SQLite for example) imposed by either the software or the politics behind it... then you need a framework flexible enough to let you go around these hurdles.

Summarizing: OAuth(2) is really a must if we don't want to pretend that every developer in the world uses Delphi/mORMot... in the meantime - waiting for OAuth(2) - a HTTP Basic Auth inside a TLS channel with some more flexibility would be good enough (temporarily).

Pardon me for the intrusion, I used to teach Operating Systems Security at the University back in my country of origin, and I agree with Sabbiolina on the fact that a fixed salt is a pretty weak solution.
In fact your authentication scheme is so peculiar that it's pretty easy to "guesstimate" the REST service was built with mORMot, and your library is open source, therefore it would take seconds to an attacker to download your source code and realize the salt is constant. Using such information it would be fairly easy to bruteforce the back-end DB directly.
On top of that: a constant salt and no salt at all is basically the same thing from a cryptoanalytical strandpoint, as 2 salted SHA256's of the same password will result in the exact same has code:
- SHA256 of "saltMyPassword" is identical to SHA256 of "saltMyPassword", whereas
- SHA256 of "1234MyPassword" is not the same as SHA256 of "5678MyPassword"
In the latter case, in fact, because of the 2 different salts, the hash codes of the same password would be different, de facto preventing most linear and differential crypto-analysis attacks.

If I invert the parameters and use them the way you wrote, it doesn't compile.
That's why I inverted them.
The compiler says: there is no overloaded version of that function that can be called with these parameters
(maybe I have to update to the latest mORMot nightly build? I downloaded the latest only few days ago...)

Have you run the project "as administrator" at least once?

So... the first query works because RoboMongo sends it to MongoDB in "shell mode", and instead fBListColl.Remove expects a query written in "strict mode"?
Is that what you mean? I'll give it a try...

Thank you, the fix works.
I will also have a look at TSynPersistent and TSynAutoCreateFields as you suggested.

Ok... I'll prepare an example.

Here's where you lose it:

function TMongoConnection.GetJSONAndFree(Query: TMongoRequestQuery; Mode: TMongoJSONMode): RawUTF8;
var W: TTextWriter;
    ReturnAsJSONArray: boolean;
begin
  ReturnAsJSONArray := Query.NumberToReturn>1;
  W := TTextWriter.CreateOwnedStream;
  try
    if ReturnAsJSONArray then
      W.Add('[');
    if Mode=modMongoShell then
      GetRepliesAndFree(Query,ReplyJSONExtended,W) else
      GetRepliesAndFree(Query,ReplyJSONStrict,W);
    W.CancelLastComma;
    if ReturnAsJSONArray then
      W.Add(']');
    W.SetText(result);
    if (result='') or (result='[]') or (result='{}') then
      result := 'null';
  finally
    W.Free;
  end;
end;

In this function you only check if Mode is equal to modMongoShell or not. Instead of that if..then there should be a:

    case Mode of
      modNoMongo: GetRepliesAndFree(Query,ReplyJSONNoMongo,W);
      modMongoStrict: GetRepliesAndFree(Query,ReplyJSONStrict,W);
      modMongoShell: GetRepliesAndFree(Query,ReplyJSONExtended,W);
    end;

The function ReplyJSONNoMongo was not existing, so I created it:

procedure TMongoConnection.ReplyJSONNoMongo(Request: TMongoRequest;
  const Reply: TMongoReplyCursor; var Opaque);
var W: TTextWriter absolute Opaque;
begin
  Reply.FetchAllToJSON(W,modNoMongo,false);
  W.Add(',');
end;

With these changes everything works perfectly.

Unless I'm very wrong here... something doesn't work as I thought.

Here's the method I'm using:

rutf := fStatsColl.FindJSON('', '', 1, 0, [], modNoMongo);

And after calling this method, here's the contents of the rutf variable:

'{"_id":"54F79A32F6A1078C08487DE7","FirstStart":{"$date":"2015-03-06T19:03:35"}, ...........

See? The $date Mongo-date-field identifier is still there.

Wait... I'm not sure I understand here. This is what I do:
- I use ObjectToJSON with [woDateTimeWithMagic] to create a JSON that I can insert into MongoDB
- Later on I query the MongoDB and use the JSONtoObject to restore the object I read from MongoDB into a new object
So of course the JSON is in Mongo format, because I receive such JSON by querying the MongoDB...
How can I do that and correctly convert dates back and forth?

I'll try it. Thank you.
Awesome project this mORMot! Kudos!!

Just my 2 cents: we've built a REST service with mORMot and a Delphi client to consume it (which works very well) but not a day goes by without a customer asking us if they can consume our REST service via their own web apps (written in PHP, Ruby, Python, ...) and the first thing they ask is OAuth2 support, as the client-side of it comes hassle-free in practically any web application programming language.
I know that, with a little bit of effort, they could implement the current mORMot auth scheme in PHP, Python (etc) but the argument is "why should we do it, when there is a standard that the world is already using (OAuth2) and that our development tools already support amazingly well?"
So, in my humble opinion, OAuth2 support is more than a nice-to-have feature... it's a very desirable one.
Thank you!

I actually did. Together with a friend of mine we had already made those changes, tested them, and we were getting ready to commit them for your evaluation... but once again you've been faster, so we will just stick to your official changes.
By the way, let me share my appreciation for mORMot once again, it's truly a well-thought-out and well-designed library. My sincere congratulations!

Errata, please in the above code use the following code in place of TForm1.Button2Click and see what happens:

procedure TForm1.Button1Click(Sender: TObject);
var
  json: RawUTF8;
  i: integer;
  obj: TMyObj;
  res: boolean;
begin
  obj := TMyObj.Create;

  for i := 0 to 1999 do // ObjectToJSON, let's call it 2000 times
    json := ObjectToJSON(obj, [woHumanReadable]);
  for i := 0 to 499 do  // now let's call JSONToObject only 500 times
    JSONToObject(obj, @json[1], res, nil, [j2oIgnoreUnknownProperty]);
  (* the above only leaks 1 time *)

  for i := 0 to 1999 do // now ObjectToJSON and JSONToObject 2000 times in the same cycle
  begin
    json := ObjectToJSON(obj, [woHumanReadable]);
    JSONToObject(obj, @json[1], res, nil, [j2oIgnoreUnknownProperty]);
  end;
  (* the above leaks 2000 times *)

  FreeAndNil(obj);
  MessageDlg('Done. Now close the program to see 2000 memory leaks... one per each iteration of JSONToObject.', mtInformation, [mbOK], 0);
end;