Multi-tenant onprem solution reaching correct endpoint, but wrong SOAP package

Hey there,

I'm currently working on a very curious problem with one of our applications.


I have 2 browsers open to simulate 2 customers, both on-prem.

Short version to log in the first guy I do 

ConfigFile.WebServices.RemoteBaseURL = "host/remote/services82";
ConfigFile.Services.ApplicationToken = "123";
ConfigFile.Services.DefaultMode = ServiceMode.Remote;
SoSession.Authenticate("user","pass");

This works correctly.

Now the second user tries to log in and the code goes:

ConfigFile.WebServices.RemoteBaseURL = "NEW-HOST/remote/services84";
SoSession.Authenticate("new-user","new-pass");

This does not work.

I also tried clearing out the session prior to the new request:

SoContext.CloseCurrentSession();
HttpContext.Current.Session.Abandon()

Didn't help.

Upon further inspection of the SOAP package sent for the second request I can see that it sent a package with the expectation of working with a services82 endpoint as it did with the first user, even though the RemoteBaseURL is a services84 endpoint.

POST https://customerHost/Remote/Services84/SoPrincipal.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.superoffice.net/ws/crm/NetServer/Services82/SoPrincipal/AuthenticateUsernamePassword"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ApplicationToken xmlns:h="http://www.superoffice.net/ws/crm/NetServer/Services82">token</h:ApplicationToken>
</s:Header>
<s:Body>
<AuthenticateUsernamePassword xmlns="http://www.superoffice.net/ws/crm/NetServer/Services82">
<UserName>user</UserName>
<Password>password</Password>
</AuthenticateUsernamePassword>
</s:Body>
</s:Envelope>


So I guess the question is, how do I make sure that the authenticate SOAP request uses the Services endpoint that the RemoteBaseURL indicates for every on-prem tenant our application is communicating with?

RE: Multi-tenant onprem solution reaching correct endpoint, but wrong SOAP package

Hello Jonas,

Were you able to solve this?

We have a similar issue for our app. In our case it happens for online tenants, when the endpoint that is enabled for our app changes (e.g. from services87 to services88).

Would you mind sharing your solution if you found any?

By: Véronique Borel 28 Oct 2020

RE: Multi-tenant onprem solution reaching correct endpoint, but wrong SOAP package

I don't know if I would call it a solution.

We have enforced the same endpoint version for all customers on the same app for onprem.

So for example I know in some apps we are enforcing services86, hardcoded in the application.
This of course sets requirements to our onprem customers, some might be forced to updating their SuperOffice installation.

For online, I don't believe we have any issues with varying endpoint versions, but that could be down to the way online authentication is implemented in the code, I'm not entirely sure.

By: Jonas Degn 28 Oct 2020

RE: Multi-tenant onprem solution reaching correct endpoint, but wrong SOAP package

Hi!

Jonas, You do not have to set the ApplicationToken for onsite installations. That's for online only.

Have you tried surrounding your calls in a an SoDatabaseContext? Here is an example I posted a few years ago. Since the ConfigFile.WebServices.RemoteBaseUrl is stored in a context variable, it makes sense to encapsulate that so each context has it's own "version" of it. 

Hope this helps!

By: Tony Yates 28 Oct 2020

RE: Multi-tenant onprem solution reaching correct endpoint, but wrong SOAP package

Tony I can see that we do as a matter of fact use a SoDatabaseContext in 1 case, when we do SoSession.Authenticate for our online customers.

We can try and do the same for the onprem Authenticate call, but would that be enough?

There is no way we can encapsulate every SuperOffice call in this SoDatabaseContext across every single application, that would be a massive task. If that were the case then I'd rather just switch to REST.

 

By: Jonas Degn 28 Oct 2020