Now that we have two clients working in command line windows (i.e. CGIs) able to talk to the authorization server to swap their vedor’s UA-usernametoken or the record owner’s User-usernametoken for an Access token, we have to focus next on the authorization grant case. But BEFORE WE DO, lets imagine we were just going to use the client-credentials grant – be a (server-side) application (such as a CGI) that has UA-rights to talk at a a privileged “application” level of permission to the odata API.
Let’s update our shipper client, a WPF app, to prove that it can apply the resource-grant swapping of usernametokens for access tokens. Rather than hand code the test call, lets use the correct mechanism – an ODATA proxy. So, as usual let’s follow instructions and figure out why we don’t understand what is said.
First, update the tooling in visual studio – since for unknown reasons the service reference tool cannot apparently read the metadata from odata and produce the proxy.
To ensure it all works with the beta release of code we are using for odata hostsed in webAPI 2.2, lets follow how to modify the above:
With the odata server know to be running (without debug) and working as the webasip[ v2.2 based resource server (on http://localhost:38385/odata, per metadata reference, above), we run the custom tool, as commanded:
to get our client proxy:
How we test and secure it is a DIFFERENT question! BUT ITS not too hard (having removed the security guard at the controller, for now).