Token/Roles not working with TMARSNetClient

[Stuart Clennett 15]

Hi, 

 

I made a new MARS based app (using the template from MARScmd) and I spent quite a while trying to get Roles working.  

 

I discovered that if the client app uses TMARSNetClient, then the token received on the server-side (via `[Context] Token: TMARSToken` is empty, and so none of the roles based access worked at all (403 received for every request).  But if I replaced the TMARSNetClient with a TMARSClient (and made no other changes) then the token appears as expected on the server side and the roles etc worked fine.  I guess this is a bug in the library.  

 

Is there any real difference between the two clients? (Other than one uses Indy and one uses THTTPNetClient ?)

 

Thanks,

Stuart

 

 

[Andrea Magni 75]

Hi, I just made a quick test and everything run smooth here.

Please post your code and we can investigate together.

 

Here ( https://www.dropbox.com/s/1ak4fdru3lrs2my/TestRolesProject.zip?dl=0 )  you can find a simple project, built with MARSCmd from MARSTemplate and then I added a simple helloworld/json method allowed only for 'admin' role.

The [Context] Token: TMARSToken get valued correctly and the client (included in the same groupproject) at designtime seems to work properly (you can authenticate but setting Username and Password [beware: password is the hour of the day you are running the demo] on the TMARSClientToken component and perform a POST request, inspect the Roles property and see them correctly valued) and then you can execute the helloworld/json resource (again, from the IDE clicking "GET" in the ObjectInspector) and see results (that includes an echo of Token.Username on the serverside as well as Token.Roles).

 

The test project I attached has been built with 10.1 Berlin and then I tested it with 10.3 Rio without a glitch.

 

Let me know, I will be happy to help you out

[Andrea Magni 75]

PS: the use of TMARSNetClient (TNetHTTPClient based) with respect to TMARSClient (Indy based) brings you the benefits of using the OS http stack (including https support without having to deal with OpenSSL deployment and compression support). This may be more or less important depending on the fact you are building a multiplatform app or not...

[Stuart Clennett 15]

Hi Andrea,

 

Thanks for the demo - I downloaded but could not make it work either. 

 

1) choose POST on the MARSClientToken : the token string is showing in the token property,  UserRoles contains standard and admin as you say.

2) choose GET on the MARSClientResourceJSON and I get a "403 Forbidden" error.

 

All I did to make it work was drop a TMARSClient on the datamodule, and hook that up to the TMARSApplication  component.

 

Networking on my developer machine is working fine, not had any problems using a standalone NetClient in other apps (not via MARS I mean).   I also copied your test server and client to another PC and tried the same thing - again 403 forbidden after a successful login when using the TMARSNetClient.

 

I added a test method that logged in and ran the GET with each type of client in turn.  The output is as follows:

Login via TMARSNetClient successful
Attempting GET with TMARSNetClient 
403: Forbidden
Login via TMARSClient successful
Attempting GET with TMARSClient 
{"Now":"12:39:35","Token.UserName: ":"admin","Token.Roles:":"standard,admin

Strange.  If there's anything else you'd like me to test, please let me know.

 

Kind regards

Stuart

 

 

 

Edited December 3, 2018 by Stuart Clennett

[Stuart Clennett 15]

PS - I have uploaded my slightly edited version of your demo app here:  https://www.dropbox.com/s/li7cznhsi13upct/TestRolesProjectClient.zip?dl=0

 

PPS - Yes https support natively *would* be very useful 🙂 

[ertank 27]

There is Fiddler application which can help you monitor raw packets in/out. Might be of help.

[Andrea Magni 75]

Thanks for you example, @Stuart Clennett

This is what I get when I click the Test button:

 

Login via TMARSNetClient successful
Attempting GET with TMARSNetClient 
{"Now":"09.22.22","Token.UserName: ":"admin","Token.Roles:":"standard,admin"}
Login via TMARSClient successful
Attempting GET with TMARSClient 
{"Now":"09.22.22","Token.UserName: ":"admin","Token.Roles:":"standard,admin"}

 

At this point I am starting to think there is something different in the Delphi version we are using (the authentication is actually endorsed through cookies (you may want to switch from cookies to Authorization header changing TMARSClient.AuthEndorsement property on both components and see what happens)).

I am not aware of bugs in this area for Berlin but I may be missing something...

 

Let me know please

 

[Stuart Clennett 15]

Hi Andrea,

 

<sorry for delay>

 

As you suggested I have added tests for "AuthorizationBearer" and I get the following output now:

 

== NetHTTP ==
Login via TMARSNetClient successful (AuthEndorsement=Cookie)
Attempting GET with TMARSNetClient (AuthEndorsement=Cookie) 
403: Forbidden
Login via TMARSNetClient successful (AuthEndorsement=AuthorizationBearer)
Attempting GET with TMARSNetClient (AuthEndorsement=AuthorizationBearer) 
{"Now":"10:36:08","Token.UserName: ":"admin","Token.Roles:":"standard,admin"}

== Indy ==
Login via TMARSClient successful (AuthEndorsement=AuthorizationBearer)
Attempting GET with TMARSClient (AuthEndorsement=AuthorizationBearer) 
{"Now":"10:36:08","Token.UserName: ":"admin","Token.Roles:":"standard,admin"}
Login via TMARSClient successful (AuthEndorsement=AuthorizationBearer)
Attempting GET with TMARSClient (AuthEndorsement=AuthorizationBearer) 
{"Now":"10:36:08","Token.UserName: ":"admin","Token.Roles:":"standard,admin"}

 

Note that with NetHTTP, the cookie endorsement does not work, but the Bearer endorsement does work.

 

I hope this helps  (I've attached the updated test app)

 

Stuart

TestRolesProjectClient.zip

[Andrea Magni 75]

I am starting to think it's something related to Delphi version (Berlin).

There are entries in quality.embarcadero.com about TNetHTTPClient and I found this: https://quality.embarcadero.com/browse/RSP-14301

If the client is not sending cookies (and AuthEndorsement is set to Cookie), your situation is explained.

 

The fact it works on my side may depend this may not affect all Berlin versions (I am using Delphi 10.1 Berlin Version 24.0.25048.9432, Berlin update 2 anniversary)...

 

Do you have a chance to check with other Delphi versions? Or maybe someone else with Berlin may try to reproduce this?

 

Thanks

[Stuart Clennett 15]

Hi Andrea,

 

I've asked another developer to run the tests.   I only have 10,1 with no updates - I will try and install update 2 in the coming days to see if that makes any difference.

 

Thanks

Stuart