mORMot Open Source

avista

Member

Registered: 2014-01-06

Posts: 63

Interface Based Services - Authentication

ab,

I'm having success with the help you provided in http://synopse.info/forum/viewtopic.php?id=1555 for AJAX calls from Javascript in the browser, so thanks again.

Now, I'm trying to understand the authentication process and get it to work.  I've read about authentication in the v1.18 documentation, but I'm still not clear on how to add credentials in the server for users and user group membership (I'll need to update the server periodically when new or existing user credentials are created/updated in my existing database).  I've looked at the authentication classes and forum, but do you have any other examples (perhaps I overlooked them or missed key forum replies) on using and extending/customizing them?

I'm also not completely clear on the difference between the two functions below (Project 14) and what is different between 'Weak' and 'regular' HTTP /TCP-IP, except that one must be using a weaker authenticaion mechanism.:

'Weak HTTP / TCP-IP'

TSQLRestServerAuthenticationNone.ClientSetUser(Client, 'User');

and

'HTTP / TCP-IP'

    Client.SetUser('User', 'synopse');

On an unrelated note, I'm wondering if the following page should reference v1.18 instead of v1.17 of the documentation, because it wasn't clear at first that there was an update:
http://synopse.info/fossil/wiki?name=Do … umentation

This might help others like me, who are new to the framework.  Also, is there a nightly build of the latest updated PDF documentation too (or updated wiki version)?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Interface Based Services - Authentication

About weak authentication, the SAD pdf is somewhat explicit:

Weak authentication

The TSQLRestServerAuthenticationNone class can be used if you trust your client (e.g. via a https connection). It will implement a weak but simple authentication scheme.

Here are the typical steps to be followed in order to create a new user session via this authentication scheme:
- Client sends a GET ModelRoot/auth?UserName=... request to the remote server;
- Server checks that the transmitted user name is valid, i.e. that it is available in the TSQLAuthGroup table - if the value is not correct, authentication fails
- On success, Server will create a new in-memory session and returns the associated session number (encoded as hexadecimal in the JSON result object);
- On any further access to the Server, a &session_signature= parameter is to be added to the URL with the correct session ID, and will be checked against the valid sessions in order to validate the request.

For instance, a RESTful GET of the TSQLRecordPeople table with RowID=6 will have the following URI:

root/People/6?session_signature=0000004C

Here is some sample code about how to define this authentication scheme:

// on the Server side:
  Server.AuthenticationRegister(TSQLRestServerAuthenticationNone);
  ...
  // on the Client side:
  TSQLRestServerAuthenticationNone.ClientSetUser(Client,'User');

The performance benefit is very small in comparison to TSQLRestServerAuthenticationDefault, so should not be used for Delphi clients.

To add users and groups, just use the ORM commands over the two corresponding TSQLAuthGroup and TSQLAuthUser classes:

Per-User authentication

On the Server side, two tables, defined by the TSQLAuthGroup and TSQLAuthUser classes, will handle respectively per-group access rights (authorization), and user validation (authentication). In the database, they will be persisted as AuthGroup and AuthUser tables.

The Server will search for any class inheriting from TSQLAuthGroup and TSQLAuthUser in its Model. By default, you can use plain TSQLAuthGroup and TSQLAuthUser classes - and if none is defined in the model, and authentication is enabled, those mandatory classes will be added. But you can inherit from TSQLAuthGroup and TSQLAuthUser, and define e.g. your own fields, for any custom purpose at Group or User level. The exact class types are available from SQLAuthUserClass and SQLAuthGroupClass properties of TSQLRestServer.

Since the whole records will be loaded and persisted in memory at every authentication, do not store too much data in those tables: for instance, do not put historical data (like previous client activity), or huge BLOBs (like detailed pictures) - a dedicated table or set of tables would be a better idea.

(...)

So you can use Client.Add(myUser) to add a new user.

Client.SetUser() is just a shortcut over the ClientSetUser() method.

I suppose we will switch very soon to 1.18 revision.
It is more than one year than we did not upgrade the revision!

The PDF is updated almost every evening, when the documentation has been updated during the day.
There is no wiki/html site available yet. Just a blog which reflects not the latest state of the documentation, but introduce new concepts (so can be deprecated after some time).
The SAD pdf is the main entry point for documentation.
Thanks for taking the time searching in it!