mORMot Open Source

I'm seeking some clarifications on how it all hangs together using the approach illustrated in this sample:
1) Is the service object only created/destroyed once per the entire server lifetime, or are there cases when it's re-created?
2) I have noticed that the service calls are happening in different threads from call to call, is this guaranteed, or can threads be re-used, i.e.: is there a fixed pool of threads? This would also have implications on how I call things from these service methods.
3) There's apparently no built-in session support with this approach, is this correct? I don't want to go root/Auth for this, but I will need session support, so if I'm correct, I'll need to write my own session support, probably within the context of this service class if that's a single instance that exists for the entire process lifetime.
4) All methods return JSON in the same format with "result" packed as an array (while I only want to return 1 value here), plus an extra "id"=0 parameter - can I have more control over this format with this approach and what is this last "id" parameter? In fact, I'd probably prefer to just have the automatic {}'s around my values.

TIA, Alex.

Hi!

I'm a total n00b with mORMot and still trying to figure out how things work, so please be patient with me ;-)

I'm trying to implement a rather simple REST server over HTTP(S), with no database access and no default authentication, but I do need session support (I just want to store a few session-specific values per session, as I could do in IntraWEB).

Now, since sessions require authentication, but the latest version of mORMot has Windows Authentication support, my idea was to let mORMot authenticate the user with SSPIAUTH specifying an empty user name. Of course, the next issue I'm hitting is that the Windows name needs to be pre-configured on the server to allow access and I'd like to avoid it. Is there any way to allow access to everyone somehow? I.e.: either with no configuration files/databases at all (preferably), or at least with a configuration file that has "*" or "ALL" or "EVERYONE" for a name?

The next thing is that I'm not going to use this server with a Delphi client, so
1) I need to document all URI's my server will expose for the users, who will then be able to implement the client in any language;
2) I would really like to drop this entire authentication process along with the root/Auth URI's, primarily to keep it short and simple, and
3) I'd like to keep it all in clear text as much as possible, to avoid requiring the users to use any hashing or encryption algorithms that may not be readily available in their language of choice.

I will need some authentication internally later on, but I will need to build it all myself, i.e.: I'll have additional methods exposed through REST for the users to provide their credentials. That's mostly because I need more than name/password values. But also because I will be authenticating the users against a third-party provider: I do not know what names/passwords may be valid there and cannot have a database of them pre-configured for this service in advance.

Incidentally, if the user can be authenticated transparently in the background via the Windows Authentication (SSPIAUTH), I will happily use their Windows User Names for logging and any kind of audit trail as may ne necessary.

So, to summarize:
1) I need to either disable and remove all and any authentication, including the need to go through root/Auth URI's, or
2) Use SSPIAUTH authentication, but somehow avoid using Auth URI's and also allow access to all and every connection.
plus additionally
3) I need to figure out the URI structures for all requests and so far I have not found any detailed reference about the URL structure. In fact, if there are any special internal URI's that can return such details, effectively making the server self-documenting, it would be even better.

Any pointers will be appreciated! Even if it turns out that I'm asking the wrong questions or even looking at this problem from a wrong point of view...

TIA, Alex.