Developer Communication - Issues Authenticating 3rd Party access to MYOB customer’s ledgers.

Hi Mike_James

Yep have to agree with you both - a dismal mess by MYOB on the par with CrowdStrikes mess.

I think @MikeJames is onto something regarding a 3rd party IAM taking over MYOB's security tokens - the addition of the prefix "ory......   to the codes and tokens seems to be the beginning of this mess.

Like @Mike_James I am not a primary .Net user for access to MYOB's API so fixes from the API forum (mostly .Net based) aren't useful to us per se, however, since this mess rolled over us I have brought up to speed the old 2010/2013 VB.NET API SDK MYOB utility - updated and got it working so that I can now keep abreast of MS Access & VB.Net changes.

However, in the end as @Julia alludes to the browser change was a red herring and in fact, in my opinion, MYOB darting up the wrong tributary for the source of the problem - it was the format of the returned payload that had changed AND the token format because it was either being created by a 3rd party IAM www.ory.sh or the change wasn't the browser but the whole internal token producing code - we will never know.

The end result was simply us developers were treated as 2nd rate citizens and the changes were dumped on us without out due process, consideration or thought which suggests something deep within the bowels of MYOB went wrong and some collective rear-ends need re-assignment.

See my separate post yesterday but in the end the fixes to MS Access code and VB/VC#.Net codes was simple and likely would have been worked out quickly by the collective brainpool that this forum provides. 

The failure was "WE WERE JUST NOT TOLD" and then lead on a wild goose chase regarding browser type - sure this might ultimately lead to some more adjusting of our code but it was NOT the critical change that brought the camel down.

Wake up MYOB - we developers are a critical mass and such disasters do you a lot of damage.

The Doc

Hi eJulia , thanks for the updates, I can definitely understand your views on this situation. For further help from MYOB on this, you will need to get in touch with the API support team here.

I had it working for 3 of my 4 applications briefly and have been testing, as responsible developers do before deploying new versions. Today I find it is not working again so took a look at what came back from the request and found that far from it being a response providing the necessary oauth token and possibly a few other pertinent data items I had got back a page or so of a html ranting on about how wonderful MYOB was for small developers. If someone thinks that sort of thing is appropriate to shove in the faces of the clients of add-on developers whenever they install the add-on software on a new PC or for a new employee they should think again.

It looks as though someone is of the impression that this authorization only gets applied when a fresh new developer starts up a new ad-hoc app for in-house use. I suspect that the perpetrators are probably unaware of how this is used and driven by some marketing/fashion motivation, quite unaware of any change management process.

Myob is losing ground to Xero partly because Xero has a better range of add-ons. Breaking the existing add-ons is a long way from how to fix that.

Could you please escalate this. It cannot just be fixed by linking to other developers discussions as to how to get round the problem. It is simply not acceptable to have add-ons being broken by ad-hoc changes without notice. The change management process should involve planning and notification well in advance, similar to the way it was managed for the upgrade to use TLS1.2 back in 2017, when we were given ample notice to enable us to prepare new releases.

Yes, I have benefitted from the advice given by Steve_PP but it is too much to expect him to keep on helping with on-going issues. He may have solved this problem and has helped a few of us to do so too but some of us do have on-going issues.

I have just had to promise a user that their latest renewal will be extended to reflect the period that they cannot use our system. They will not be the only ones. That on top of not getting new sales until we have this solved.

if MYOB were advised that the change would be transparent to all add-ons they perhaps did not understand what a variety of add-ons there are out there. Also such statements from people/organisations selling something need to be taken with a full handful of salt. Some testing would have been in order and roll-back immediate once the problem emerged. 

What they should have done is leave the existing structure/process in place, implement the new one via a different URL and notify all of us developers as to what they were doing and that they would be closing down the original after we all had sufficient time to adapt, say sometime next year. that would provide time for everyone both within MYOB and us developers to test in development, not on live systems.

I still think this demonstates a shocking lack of proper change management process.

Do you not have a change management process?

I an somewhat horrified that you have not:

1. Realised that most developers do not update their systems just to keep them fashionably up to date, too busy reacting to basic business functionality requirements
2. Announced this change well ahead so we could prepare for it
3. Supplied sample code, also well ahead, to assist in that preparation
4. Backed this change out, with suitable apologies, when the scale of the problem emerged

You give the impression that you think it is just a matter of someone (end users?) upgrading their browser but in fact it is a matter of rebuilding a Windows application to use a completely different set of browser classes, with different, non-equivalent properties and methods. It all has to happen within the software and the classes it uses. Replacing IE with Edge on the outside does nothing to solve the problem.

Most people selling Windows software, like us and many of your add-in developers, would need to go through a process of:

1. Modifying code and testing it

2. Regression testing to ensure that the changes did not break something else

3. Updating the deployment package to ensure all the necessary addins get in

4. Testing the build install package

5. Updating to a web site

6. Notifying end users that they really do need to upgrade

This does not happen over a weekend. Also finding out that it needs to be addressed because one of our users raised the issue with us, probably about a week after you did it does not help.

We cannot take on new users so no new customers, no license sales until this is fixed.

For anyone still needing support with updating.
One of the developers in our community has shared some code and instructions that helped them to update and others have also been successful following this advice.
Check it out here
Thanks to Steve_PP for sharing with the community