JWT Authorization and TRemoteDb

Hi, maybe i'm trying to do something weird...

1) i have a TXDataServerModule, that i use to create / distribute a Jwt Token. All right until here

2) The token is correctly distributed to clients that ask for it, via

XClientAuth.Service<ILoginService>.Login(GetUriUser, GetUriPassword);

3) i have a TRemoteDBModule on the same server, with a TJwtMiddleware added (same secret key of ILoginService)

4) i have a TRemoteDBDatabase component on client. On event RequestSending i have made

procedure TDDb.RequestSending(Sender: TObject; Req: THttpRequest);

    if authtoken <> '' then
        Req.Headers.SetValue('authorization', 'Bearer ' + authtoken);


Authtoken is the string containing the JWT Token. Ok, whe i debug all process, i see that the TJwtMiddleware correctly uses the authtoken to create the IUserIdentity . But next, when (in the chain) the THttpServerContext goes to TRemoteDBModule, this module refuses authentication, cause he needs BasicAuthentication parameters in Content Headers, not JWT.

First question: i was sufficiently clear ?

Second question: it is as it seems, so we can't use a JWT Token to validate traffic with TRemoteDb ?

Thank, ciao !


Hi Arnaldo,

Yes, clear enough, thank you.
TRemoteDBModule by default uses Basic Authentication, by setting UserName and Password properties with initial values. Just clear those properties to make sure it doesn't try to enforce Basic Auth:

Module := TRemoteDBModule.Create(...);
Module.UserName := '';
Module.Password := '';

Hi Wagner,

it doesn't work, i have cleared UserName and Password properties, reintroduced the JWT Token middleware, but no success.

Until now i'm missing the exact point how/where a TRemoteDb module returns "401". I'm at the point where , in unit RemoteDB.Server.Module, at row 354 the

          DB := FindDB(Context);

doesn't find the db . My Context.Request.headers doesn't contain the 'remdb-db-id' value.

If i exclude the JWT token and i re-use Basic Authentication, all is fine and the Context.Request.headers contains the 'remdb-db-id' value.

I know, it's too vague to have an answer. I'll try it further, maybe i will find the reason.



We've noticed an issue here indeed. Please contact us via e-mail to receive a patch.
Ok, i contacted you via e-mail. In the meantime, i've maybe found some thing, related to TBasicAuthenticationProvider class. I will wait your patch, and i'll send to you some info.

Wagner, so many thanks, all is fine.
That IF condition permits to bypass the Basic Authentication, so an ID for the database is assigned, and from there the communications between server and client are ok.

I will continue to explore the JWT authentication with TRemoteDb, thank you so much !

P.S. = all of this was caused by some weird penetration tests, and the result was that SSL + Basic Authentication was not enough, because with TRemoteDb the Sql code is transmitted from client to server (i know, we were conscious about this "limit"). Using JWT we haven't resolved the problem, but we are trying to make testers sweat !



Did this issue ever get resolved in published code? I have followed this thread and, based on my results, I appear to be hitting the same brick wall when it comes to JWT and RemoteDB. Each time, it gets to the same point in code the DB does not resolve, even though I have verified the creation of the User info. It is possible that I have another error, as I have deleted and recreated both the client and server pieces repeatedly. The final result is just as described in the previous posts though.


Follow up. Went back and rebuilt the apps again to ensure no lingering trial code. Same Issue BUT this time I tracked an issue with using dbGo as the db connection. The error was CoInitialize was not called when the db was attempted to be created by the server. I had the code in my server components but not when the server auto created the db again. Once I removed dbGo and replaced with a Firedac connection the db created as it should for each connection. Just thought you would like to know.

Kelvin (for Steve)

1 Like