In my country, there’s a saying: “A good horse has a hundred flaws; a bad one has only one.” It’s bad.
People have asked me why I am doing this, and if I hate Web services because I’m blogging about their flaws. In fact, I love Web services, and as I said in the first post in this series – they are great. They are a good horse. A winner.
The reason why I am doing this is because I want to share the problems I encountered over months of working with Web services intensively, as well as the solutions or workarounds I identified.
Today, on the repertoire we have another security-related glitch, which has been confirmed to me by Microsoft, but as far as I know there has not yet been a hotfix for this.
Bug #4: accessing Web services in multi-company scenarios.
Soren has taught me yesterday that some of the bugs I encountered have been properly disinsected by Microsoft, so other than the workarounds I suggested, there is an option to apply the hotfix and forget about that one.
Today, I’ll explain a not so critical bug, as the one yesterday, but depending on what exactly you do with Web services, it may be more than just a nuisance.
Hello, bug #3: accessing WSDL without database-wide permissions.
Microsoft Dynamics NAV comes packed with a set of predefined roles for many tasks such as editing or posting journals, creating sales orders, editing fixed assets, etc. It also comes packed with a SUPER role, which can do just about anything it wants.
There are two problems with the SUPER role. They are kind of pretty much entangled together.
The first one is—SUPER can do just about anything it wants (um, did I say that already?). The second one is—there are far more super users out in the wild than there should be. Is this your experience, too?