C# WebBrowser -> WebView2 solution
Hi Here is a solution for those with C#.NET apps that need to update the internal browser their desktop app invokes when OAuth is required due to breaking changes enforced by MYOB in Aug 2024. In...
Forum Discussion
Hi Steve_PP
Thanks for the above code - I was almost forced to spin up a VB.NET/BV#.NET version thinking all my Access code was now useless - that is the rabbit hole that this MYOB mess has forced upon us.
However, I have got my Access code back online as of last night - and the delay in doing so was the mis-information coming out of API tech( apparently they hadn't been told of the changes made to the server) - however this failed navigation error is not an error, as it turns out (prior to all this change we got a blank page and I could extract the code embedded in the page source) - the returned access code is/was, it seems, embedded in a json payload in the form of a page - this is not happening now - so this error whether using chrome/IE/Edge was not an error - the code was legit - but so far I haven't been able to capture it out of the old webbrowser in Access - however with Antview2 the webbrowser2 Edge it came with a method that enabled easy capture.
I am hoping I can do without Antview2 and capture this code in an ordinary browser.
The Doc
Here's some other info that may be useful. From my reading (not testing,) WebBrowser, available in .NET, runs in IE7 mode by default. There are some reg keys you can use to push it up to IE11 but MYOB have said even that won't be supported soon, so switching to WebView2 makes sense.
After you make the original GET request, after a lot of bouncing around (about 5 calls, which you can see if you put a break on webView2.NavigationStarting in my code) you end up with a return result that includes your chosen redirect URL, e.g. http://desktop, and a bunch of query parameters that include the code you need to POST to get the access tokens. I'm guessing that 'bouncing' now won't happen if you're not using a modern browser (maybe the issue is javascript related?)
The return URL (if using http://desktop) will definitely result in a navigation error because it doesn't point to a valid resource, but is serves the purpose of presenting the code, which you can extract for the next step. I don't remember seeing a page navigation error with the WebBrowser control, probably because the form was closed before it was rendered. With my code, you do get a flash of the error page before the form automatically closes.
I guess if you can't find suitable browser to invoke within your app, you could start an external browser to make the GET request, and make the redirect URL something like http://localhost:1234 and set up a port listener in your app to retrieve the result. Or if that's also a problem, simply provide instructions for the user to copy and paste the redirect URL back into your app so you can extract the code.
Hi Steve_PP
Since posting my last I have played around with my trial app I keep on my laptop - originally built before I had any code for my client apps.
But determined I was of keeping the old Access browser I finally found a way of capturing the returned code even though the page errors - prior I could use
Me.WebView.Object.Document.documentElement.outerHTML to capture the page = source code - but that doesn't work now.
I am a bit peeved at having to buy an Antview2 licence which isn't cheap so I am going keep running my code using the std VBA Webviewer - here is what works
Me.WebView.Object.Document.URL
Result = "res://ieframe.dll/dnserrordiagoff.htm#http://desktop/?code=ory_ac_rTxyMWokubBE..........................Sk47H_QJi-IaiieQ4rs6Perq8AZaN6Gv-yTOE&scope=CompanyFile+offline_access+openid&state=887b5f483a0cefc39eee91c2"
And this works fine - the access code is legit - it gives me an access_token and a refresh_token.
I am betting that when MYOB finally switch fully over this will still work - so am using Antview2 on 1 website integration but configuring my other 2 website integrations with MYOB using the above.
The Doc
Ahahahahahaha! Nice work The_Doc
So much pain for so little code that actually needed changing. In .NET, if you change webB.DocumentText to webB.Url.AbsoluteUri and replace ExtractSubstring with the ExtractAuthorizationCode method I posted above you are good to go.
So what's all this about needing modern web browsers then MYOB?
eJuliayou probably want to read this.
"I am betting that when MYOB finally switch fully"
You mean there are more changes they are planning to throw at us without notice? Where in all this is their change management process?
Back in the days when I worked for large corporates (Telstra, IBM) there were change management teams who would absolutely have dropped on this behaviour. Asked questions like "Have you advised the stakeholders?" and "Have you checked when their changes to accomodate this will be ready?" not just the obvious questions like "Is it fully tested?"
One of my customers suggested, when I explained what was going on, that the appropriate reaction was a registered letter to the directors. Not going to go quite that far but this is close to putting us out of business, certainly killing sales in the near future. The faithful who love the product will hang in for a while and I am telling them to stay away from our Online Authorisation button until we have a new release but this is going to take more than just a day or two.
Even when we get it going, and I have not got a working compile yet, there will need to be full regression testing and reworking the deployment package to make sure the end users get a nice install from the download. The license certainly does not cover home visits and the customer base stretches from Katherine to the Cook Islands.
Is anyone from MYOB folloowing this thread?
Hi eJulia
Yep, they rolled the requirement for the edge browser back so that IE 8,9,10 continues to work - though they didn't give a timeframe.
It is on this forum somewhere, a belated post by MYOB and the changes (dated 16/8/24 - the original crash was the night of 7th Aug) .
However, as I suspected and I think (hope I am right) - and interestingly my exact words to Tana in api support ( though for the record Tana has been nothing but helpful and has tried to give every bit of info she had at her finger tips - but it seems, I am told, even they weren't told by the back room people) - anyway my email in return to Tana telling me about "Edge Browser", "WebViewer2" "Antview2" - my reply was Tana I think this is a symptom not the problem!
My simple fix is I am hoping the answer, that the browser has nothing to do with the problem - the token server is piping the access code back to you - it is there.
I proved this by using the desktop Edge Browser, Chrome Browser, Opera Browser, Fox Browser - the returned code line was identical - the browser type was irrelevant.
I will keep you all posted as I am running a fix with Antview2 and with the old Webview browser in MSAccess.
If I have time I will spin up a working version of a VB.Net & VC#.Net app using both browsers.
I have to build these from the ground up but it will be a good rainy day project.
If someone has got some working code for VC# I wouldn't mind a leg up or VB - I can adapt it - I write in both languages - I just find VB.NET so much simpler for my brain - VC#.NET is a pedantic language.
The Doc
