Jump to content
Stuart Clennett

Token/Roles not working with TMARSNetClient

Recommended Posts

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

 

 

Share this post


Link to post

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

Share this post


Link to post

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...

Share this post


Link to post

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 by Stuart Clennett

Share this post


Link to post

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

Share this post


Link to post

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

 

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×