You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2015-08-20 08:36:21
mORMot session recovery
In our quest for ever more robust software, I'm wondering how mORMot deals with a server restart. My tests didn't have a very elegant result. The only solution I found was to recreate the client connection, which is a problem when the connection reference has been passed down through several layers. To my mind it would be ideal if TSQLHttpClient, or some parent, could try and re-establish it's session on receiving a 403.
Offline
#2 2015-08-20 20:43:29
Re: mORMot session recovery
You can allow reconnection using the proper event.
Offline
#3 2015-08-21 06:23:23
Re: mORMot session recovery
Hi Ab,
Digging a bit further, it looks like it has to do with my custom hash. On top of that I'm also relying on HTTP Basic Auth, as the current hash can not be coded in JS without considerable effort. I'm making some changes I'd like to recommend be added to the base mORMot libraries, but will submit a full diff / pull request once I've stabilized the extension.
Offline
#4 2015-08-21 07:13:26
Re: mORMot session recovery
For JavaScript code running mORMot authentication, aka as TSQLRestServerAuthenticationDefault,
see https://github.com/synopse/mORMot/tree/ … gularJS/js
You could use HTTP Basic Auth directly in the framework, using TSQLRestServerAuthenticationHttpBasic.
See http://synopse.info/files/html/Synopse% … #TITLE_502
Offline
#5 2015-08-21 09:16:04
Re: mORMot session recovery
Hi Ab,
Yes, I am using that. The issue came in with session recovery. Currently mORMot only tries TSQLRestServerAuthenticationSSPI (if SSPIAUTH is defined ) or TSQLRestServerAuthenticationDefault on the client side. I added a new event OnClientSetUser, which would allow the Client Application to take control of how SetUser prioritizes authentication schemes. It also makes it easy to reliably add new schemes and one can do away with the initial [CustomAuthScheme].SetUser() call. There was also a small issue where TSQLRestServerAuthenticationHttpAbstract.ClientSessionSign that would keep on appending the Cookie: header.
The current hash I was referring to is the current legacy hash we need to integrate to. We're looking at upgrading that to an SHA based hashing system to allow us to take advantage of the other more secure and compatible authentication schemes.
For now we're stuck with basic HTTP Auth, sending a plain text password, so that we can calculate the database hash on the server.
My changes work now. How do you prefer I submit the changes for your approval and comment?
Offline
Pages: 1