Build 9088 API Changes AGAIN!!
Problem reported by Bruce - 11/19/2024 at 3:53 AM
Submitted
Since upgrading from build 9056 (Oct 18, 2024) to build 9088 (Nov 18, 2024), our control pane can no longer retrieve email accounts using the API.

Can you let me know what API changes have been made to the API?

Thank you.
Kyle Kerst Replied
Employee Post
A review of our release notes reveals no API related changes between 9056 and our latest:


I recommend submitting a ticket with the control panel creator and one with us if you need assistance troubleshooting that further.
Kyle Kerst Lead Internal Network/System Administrator SmarterTools Inc. smartertools.com
Bruce Replied
I didn't find any API changes in the log files, but it's not uncommon for API changes to be implemented in SmarterMail without being mentioned in the release notes.

Could you check with the developers if they made any changes that they didn't list in the release notes?
Jack. Replied
Hi Bruce?

What control panel are you using?


Bruce Replied
MSP Control.

For the time being, I have rolled back to Build 9056, which works with MSP Control.
echoDreamz Replied
Thanks for letting us know Bruce, we dont use MSP Control, but we do have our own control panel. So, waiting to hear what has changed.
Kyle Kerst Replied
Employee Post
I wanted to let you know that I've set up one of our support guys with a test environment to see if we can get this control panel setup for testing. If we're able to replicate the issue in-house we'll get a task escalated to development right away.
Kyle Kerst Lead Internal Network/System Administrator SmarterTools Inc. smartertools.com
Bruce Replied
Thanks Kyle.
Douglas Foster Replied
We have noticed that a previous SmarterMail bug has created duplicate security providers for the same Active Directory server, so different users are now on different GUIDS and we have the same name listed multiple times.   If you have the same symptom, it would explain why some users are not accessible from you control panel, and it has nothing to do with API changes, just dirty data.   We opened a ticket on this issue tonight.
Bruce Replied
Thank you, Douglas, but this is not the issue. All mailboxes cannot be edited from MSP Control on SmarterMail build 9088, and rolling back to version 9056 resolves the problem.

There seems to be a problem finding the domain when you try and edit a mailboxe as you get an error that the domain cannot be found.

The MSP Control developer working on the SmarterMail provider believes he has narrowed it down to an issue with the get-user API call, but he needs more time to look into it.
Jack. Replied
@Bruce 


The SolidCP provider for SmarterMail has been updated, we are currently doing some testing.
Bruce Replied
Thanks, Jack,

While SolidCP and MSP Control are both forks of WebsitePanel, MSP Control has been rewritten in ASP.NET 8 blazer and therefore, the SolidSP provider for SmarterMail will likely not work in MSP Control.
Derek Curtis Replied
Employee Post
Bruce,

Are, or were, they possibly using the legacy API for SmarterMail? I ask as the only changes I can see for the API relating to GetUser were documentation related, not changes to the call itself. 

And, just to make sure I wasn't missing anything, I asked the SmarterMail team and they said the same. 
Derek Curtis CCO SmarterTools Inc. www.smartertools.com
Bruce Replied
MSP Control doesn't use the SmarterMail legacy API.
Webio Replied
@Derek: This might be related to some changes in API for:


Is there any chance that clientId was added somewhere in the way and in latest build is required as a param?

Switching API call from mentioned sysadmin part (POST) of API to (GET):


for fetching user data probably fixed this problem.
Derek Curtis Replied
Employee Post
ClientID was added to that call almost 10 months ago, so no new changes there between 9056 and 9088. Also, if I understand the question/suggestion, changing the SysAdmin call to a GET is what we call a "breaking change" for the API. 
Derek Curtis CCO SmarterTools Inc. www.smartertools.com
Bruce Replied

Webio has resolved the issue with the SmarterMail provider in MSP Control.

 

The problem originated from the first API method mentioned below, which changed or broke between versions 9056 and 9088. This alteration prevented mailboxes from being edited in MSP Control.

 

https://mail.smartertools.com/Documentation/api#/reference/SmarterMail.Web.Api.SystemAdminSettingsController/GetUser/post

 

An alternative SmarterMail API method is now being used to achieve the same results, ensuring that SmarterMail functions properly in MSP Control.

Webio Replied
@Derek: I had to switch to completely different method and not just simple POST -> GET which IMHO if would be true then still this would be a breaking change because it would break things right?

Bottom line THIS method (POST - sysadmin account):


returned:

Domain does not exist.. error

So maybe it is something to check on your end and see how this method behaves.

Switching to this method (GET with Domain bearer token authentication):


allowed to fetch user datails while providing the same mailbox as first method.

EDIT: Does ClientId param for metioned POST method is required? Does this change (adding ClientId param) 10 moths ago was somewhere documented?

EDIT2: I've updated one of my SM instances to latest build and yep - take a look at screenshot from REST client app:

while the same email account details can be fetched using domain get user method
Alessandro Pereira Replied
We are having the same problem after updating.
/api/v1/settings/sysadmin/get-user

The POST method stopped working and now requests the clientid field

Now it returns the error:
{"message":"Domain does not exist.","success":false}

That's problematic,
let's update our panel to the GET method
Webio Replied
IMHO this is not related to clientid being requested since error is not telling about missing param but about domain which does not exist which is not true because domain from email param does exist in SmarterMail instance to which API request is being made
echoDreamz Replied
Can confirm here as well, the old

client.ExecuteRequest<GetMailAccountResponse>("settings/sysadmin/get-user", new { email = accountName }, adminAccessToken, Method.Post);
No longer works and returns "Domain not found" - This has been working for a while now. Also, the 

api/v1/report/user-stats/{startDate}/{endDate}
UPDATE: the stats requests started working out of nowhere, but is still wanting a clientId, seems to be OK without it however. What is the clientId param for?
Sérgio Rocha Replied
Hi,

WE have the same problem, with solidcp control panel?

Regards,

SR
Jack. Replied
@sergio rocha, What version of SolidCP are you using?
Sérgio Rocha Replied
@jack we are using the version 1.4.9 (1.4.5) We have a customized provider for smartermail.
Hemen Shah Replied
Hello
Anyone using solicp currently and to confirm if scp 1.5.1 works fine with latest SM build 9543
For us getting issue when fetching email domain, edit or new id creation with error  “could not get mail domain”

If I see release logs, it looks coz of below
  • Security: API access now follows the user whitelist/blacklist as well as System Administrator IP Restrictions for authentication.
Thanks 
echoDreamz Replied
We do not use SolidCP, but we do use our own control panel that relies heavily on the SmarterMail API, build 9543 has not caused any issues at all.
Tan Replied
Ya we also depends on SM API for our control panel too. So far no reported issue
Tan Replied
Ya we also depends on SM API for our control panel too. So far no reported issue
Sérgio Rocha Replied
The problems with the SmarterMail API were resolved several versions ago. Which version are you currently using?
Hemen Shah Replied
SCP with SM was working fine before 9543
Currently Using SCP 1.5.1 and SM build 9543, when editing mail domain in SCP it breaks with error “could not get mail domain”
Sérgio Rocha Replied
And you have sure that the domain was not delete on the email server directly ? 
Hemen Shah Replied
Its existing active domain, if i want to create new id or tried edit domain it gives error
One thing i noticed, admin ID set in SCP server login has 2FA, can this be reason ! will try though
Sérgio Rocha Replied
yes, its because of that.
Douglas Foster Replied
I found this problem recently and posted on it, so it has existed at least since build 9518, and the problem makes sense.
The API is how webmail is implemented, so an API connection is indistinguishable from a Webmail connection, other than possibly the user agent string.   This means that  you cannot get around 2FA using one of the application passwords provided for MAPI/IMAP/POP/etc.
The workaround is to configure an account with IP restrictions but not 2FA, and use that account for your API calls.   When the script needs a different user context, use impersonation rather than changing logins.
Based on another recent post, you can avoid some impersonation by using a system admin auth token and adding x-smartermail-domain="domain name" to your request header.
Hemen Shah Replied
@Sergio / @Douglas

It doesnt look like  2FA issue, tried with new admin user with / without IP restriction doesnt work.
but what i found is Build 9540 removed the SOAP endpoint `svcMailServerAdmin.asmx` — you can confirm this by running: https://YOUR_MAIL_HOST/services/svcMailServerAdmin.asmx
This returns 404, while other SOAP endpoints like `svcDomainAdmin.asmx` still return 200.

Also received SM update and to be known bug expected fix soon.

Thanks
Bruce Replied
Just in case anyone sees this and wonders if MSP Control is also broken, as both SilidCP and MSP Controls are forks of WebsitePanel.  MSP Control is working without issues with the latest SmarterMail build 9543.
Sérgio Rocha Replied
What provider you chose on your smartermail service, in the server component configuration. Are you using the 100?
Hemen Shah Replied
Yes using SM100
Hemen Shah Replied
Issue has been resolved with latest build 9546

Fixed: An issue with the legacy SOAP API and obfuscation

Thanks

Rod Strumbel Replied
Just going to add, for anyone upgrading from an older version of SM to the latest editions.  There WAS a change in communication at the Domain Admin level in the API (if you do impersonation for managing the domains).  You must now pass the mailbox in the POST parameters and not on the command line.  That hung us up for many days before sorted thru it.  Not sure if other commands are similar in modification or not, but something to check if you are having issues.  We would get a 500 error when issuing in the incorrect format.
CLEBER SAAD Replied
Some SOAP API don't work well in the latest versions of SM.
We change our control panel from SOAP api to the new REST API.

Reply to Thread

Enter the verification text