How can I access a REST API through Silverlight (With basic auth)? - silverlight

I'm trying to access a run-of-the-mill REST API through a silverlight application, but can't seem to get basic authentication to work (using silverlight 4.0).
I'm using a .NET WebClient, and setting the webclient.Credentials with a valid username/password (for the API).
I'm running into two main errors:
System.NotSupportedException: BrowserHttpWebRequest does not support custom credentials.
(this only occurs when I set the webclient.UseDefaulCredentials to false)
and
System.NotImplementedException: This property is not implemented by this class.
at System.Net.WebRequest.set_Credentials(ICredentials value)
(occurs when webclient.UseDefaultCredentials isn't set at all)
what am I missing here? Is basic auth still not supported in Silverlight 4.0?

There is an article about it here http://mark.mymonster.nl/2009/12/02/silverlight-4-credentials-weve-got-it/ and it seems the magic line is:
WebRequest.RegisterPrefix("http://", System.Net.Browser.WebRequestCreator.ClientHttp);
In my case it seems to send the credentials, but I still end up with a 401 error but I just grabbed one of my web servers to try and it may not be configured correctly, but this seems like it should work.

I would also suggest trying the open source library Hammock for REST It provides a very useful wrapper around a lot of modern web calls like REST and oAuth.

Related

How to use google.maps within an asmx web service

I need to calculate distances for some logic within a web service and assume google.maps API is appropriate. Everything I've seen is Jscript and requires a reference to the script in html tags <script>, which does not apply here. A .dll would make things obvious to me, but that does not seem to be available...
How do you access google.maps within a c# .asmx??
You will have to do the same thing that would be done by the JavaScript code you're seeing as examples. You'll want to use the WebClient class or maybe the WebRequest class to do the network I/O, but you've got to send and receive HTTP messages.
"Add Service Reference" won't work, of course.
Note that this problem is not specific to ASMX web services. You would have the exact same issue in a console program or Winforms application.

Silverlight web service call not even hitting servers

I have a custom proxy class for a single WCF web-service (takes a string in, sends a string back). The asynchronous web service call works great from my Windows Form app. However, when I call it from a test Silverlight app I get an error: Hresult 0x80000012. This error is for Extension Attributes on files I believe... Go figure.
Using Fiddler I can confirm that no traffic is making it to IIS which is hosting the service, so it isn't the usual cross-domain restriction issue. I've tried using both "localhost" (which works in the Windows Forms app) and a name defined in my hosts file just in case "localhost" was causing the problem.
I've tested it by making the async call from the UI thread and also from a thread-pool queue item with the same results.
The proxy code is basically just simplified down from what the MS proxy generator creates, setting up bindings and settings programatically instead of via config files, and I use basically the same source to compile normal .Net and Silverlight versions of the libraries involved. (Now, the MS proxy code it is based on is from a WCF web service, not from the RIA template code, so maybe there are differences there...)
Four days of fruitless search on this one. Any help or suggestions would be wildly appreciated!
Figured it out. I was using (stupidly) a backslash in part of the URL that I used to set up the service call. Most of the interior parts of the MS code handled that ok and transposed them to forward slashes -- on Windows Forms everything worked seamlessly in fact. However, the Silverlight libraries couldn't handle it and threw the very helpful "HResult 0x80000012" error.
Changing my backslashes to slashes seems to have fixed the problem!

Unit Testing the Server Interface for a Silverlight-Facebook Application

I have a Silverlight 4 client running on a Facebook page hosted on Google App Engine. It's using gminifb to communicate with the Facebook API. The Silverlight client uses POST calls to the URIs for each method and passes the session information from Facebook with each call.
The project's growing and it would be super-useful if I could set up a unit-testing system to make a variety of the server calls so that when I make changes I can ensure everything else still works. I've worked with nUnit before and I like what I've read of PEX but I'm not sure how to apply them to this situation.
What're the choices for creating a test system for this? Pros/cons of each?
How do I get started setting something like this up?
Solved. I did it as follows:
Created a special user account to be used for testing on the server that bypassed the authentication. Only did this on the test environment by checking a debug flag in that environment's settings. This avoided creating any security hole in the live site (since the same debug flag will be false there.)
Created a C#.NET solution to test each API call. The host project is a console app (no need for a GUI) with three reusable synchronous methods:
SendFormRequest(WebRequest request, Dictionary<string,string> pairs),
GetJsonFromResponse(HttpWebResponse response),
and ResetAccount().
These three methods allow the host project to make HTTP requests on the server and to read the JSON responses.
Wrapped each server API call inside a method call in the host project.
Created an nUnit test project in the solution. Then simply created tests that call each wrapper method in the host project, using different parameters and changing values on the server.
Created a series of tests to verify correct error handling for invalid parameters and data.
It's working perfectly and has already identified a few minor issues that have been found. The result is immensely useful and will check for breaking changes on new deployments.

Using ASP.NET session state with Silverlight (PRISM)

The scenario:
I have a PRISM application developed in Silverlight (4), and I'm using a ASP.NET server side application to host several web-services (which, in turn, accesses WCF-services, but that's not really important here). The Silverlight application must be able to call the web services cross-domain (meaning that the web services isn't necessarily on the same server hosting the silverlight application).
The Silverlight application consists of several modules, each accessing the ASP.NET web-services.
I do not have much experience with Silverlight and PRISM, but as far as I can see, this is not a very unusual scenario...
The problem:
My challange is, that when 2 different modules access the web-services, I get 2 new sessions on the web-server. I would have thought that since both modules live on the same HTML-page (and then also in the same browser session), they would get the same session on the web-server...?
I have tried to make the web-service Proxy-client globally available in the container (using Unity), by registering an instance (using Container.RegisterInstance), and then getting this instance whenever a module needs to make a web-service call (using Container.Resolve), but this doesn't seem to help.
However, any calls made within the same module always gets the same session on the server.
Can anyone see what I'm missing here...?
Thanks!
Jon
Looks like I found my own answer.
The problem was that my application was firing multiple web-service calls upon startup (the different PRISM-modules working independently). And when several calls were made before any responses was given from the web-server, no session (and hence no "ASP.NET_SessionId" cookie was provided) back to the client before subsequent calls were made.
My solution was to make sure I make one call (async as always), for example to a simple Ping-like web-service, then hold all other calls to the web-server until this response is back. Then, all subsequent calls are given the same Session on the server (because now they all contain the "ASP.NET_SessionId" cookie in the header).
In pratice, this call is made by the PRISM-shell, and no modules are beeing loaded before I receive the reponse. Then I'm absolutely sure that none of the other modules get trigger-happy before I have a session-state on hand.
Still, if anybody sees any other problems with this solution, I'm more than happy to hear from you.
Thanks!
Jon

Using a subdomain to identify a client

I'm working on building a Silverlight application whereas we want to be able to have a client hit a url like:
http://{client}.domain.com/
and login, where the {client} part is their business name. so for example, google's would be:
http://google.domain.com/
What I was wondering was if anyone has been able, in silverlight, to be able to use this subdomain model to make decisions on the call to the web server so that you can switch to a specific database to run a query? Unfortunately, it's something that is quite necessary for the project, as we are trying to make it easy for their employees to get their company specific information for our software.
Wouldn't it work to put the service on a specific subdomain itself, such as wcf.example.com, and then setup a cross domain policy file on the service to allow it to access it?
As long as this would work you could just load the silverlight in the proper subdomain and then pass that subdomain to your service and let it do its thing.
Some examples of this below:
Silverlight Cross Domain Services
Silverlight Cross Domain Policy Helpers
On the server side you can check the HTTP 1.1 Host header to see how the user came to your server and do the necessary customization based on that.
I think you cannot do this with Silverlight alone, I know you cannot do this without problems with Javascript, Ajax etc. . That is because a sub domain is - for security reasons - treated otherwise than a sub-page by the browsers.
What about the following idea: Insert a rewrite rule to your web server software. So if http://google.domain.com is called, the web server itself rewrites the URL to something like http://www.domain.com/google/ (or better: http://www.domain.com/customers/google/). Would that help?
Georgi:
That would help if it would be static, but alas, it's going to all be dynamic. My hope was to have 1x deployment for the application, and to use the http://google.domain.com/ idea to switch to the correct database for the user. I recall doing this once when we built an asp.net website, using the domain context to figure out what skin to use, etc.
Ates: Can you explain more about what you are saying... sounds like you are close to what I am trying to come up with. Have you seen such a tutorial for this?
The only other way I have come up with to make this work is to have a metabase that when the user logs in, it will switch them to the appropriate database as required... was just thinking as well that telling Client x to hit:
http://ClientX.domain.com/ would have been sweeter than saying to hit http://www.domain.com/ and login. It seemed as if they were to hit their name, and to show it personalized for them right from the login screen would have been much more appealing for the client base.
#Richard B: No, I can't think of any such tutorial that I've seen before. I'll try to be more verbose.
The server-side approach in more detail:
Direct *.example.com to the same IP in your DNS settings.
The backend app that handles login checks the Host HTTP header (e.g. the "HTTP_HOST" server variable in some platforms). That would contain the exact subdomain.example.com that the client used for reaching your server. Extract the subdomain part and continue...
There can also be a client-side-only approach. I don't know much about Silverlight but I'm assuming that you should be able to interface Silverlight with JavaScript. You could read document.location with JavaScript and pass it to your Silverlight applet, whereon further data fetching etc. logic would rely on the subdomain that was passed in by JavaScript.
#Ates:
That is what we did when we wrote the ASP.Net system... we pushed a slew of *.example.com hosts against the web server, and handled using the HTTP headers. The hold-up comes when dealing with WCF pushing the info between the client and the server... it can only exist in one domain...
So, for example, when you have {client}.example.com and {sandbox}.example.com, the WCF service can't be registered to both. It also cannot be registered to just *.example.com or example.com, so that's where the catch 22 is coming in at. everything else I have the prior knowledge of handling.
I recall a method by which an application can "spoof" another domain name in certain instances. I take it in this case, I would need to do such a configuration? Much to research yet I believe.

Resources