0

here's my setup:

I have an MVC3 site hosted with a www subdomain (e.g., www.example.com). My site is secured via SSL and forms authentication, backed by ASP.NET membership/role providers. I have HTTP handlers providing service capabilities under /services (e.g., www.example.com/services). These are secured through Basic authentication over SSL. I have mobile devices successfully accessing/consuming these services. I have also created a new site with an api subdomain (e.g., api.example.com) that will be my public-facing API. These services are exposed currently via WCF Web API preview 6 (eventually to be migrated to ASP.NET Web API). These services are also secured via Basic authentication over SSL. My ASP.NET membership implementation stores hashed passwords (i.e., they are not encrypted). All services serve JSON responses. All of this stuff works great.

Here's my dilemma:

I started to write a new view on the MVC site and realized it would be great to use Ajax. My specific case is to implement cascading drop-down lists. I wanted to implement this using jQuery and a new service under the api subdomain. At first I thought this would be a simple exercise and then I realized, I have no effective way to call into my own API. My clients (mobile devices) all store their username/passwords locally so this is easy. However, if the same user is logged into my site, I have their username but not their password so I do not have a direct way to access any services offered under the api subdomain.

As I see it, I have three solutions:

  1. Implement services that support the MVC site directly under the /services URI, eschewing consuming my own public API.
  2. Create a super user in my membership store (where I know the username/password) that the site uses to access services in the api subdomain.
  3. Change my authentication strategy.

It occurs to me that I probably should not utilize my own public API and would be better served using my own private services (which is ok because the logic is all shared via a facade layer).

What is the recommended strategy here? I also assume that if I were to utilize option 2 or 3, I would have to do so using JSONP. Is this correct?

Any advice would be greatly appreciated. And if more details are needed, please post and I will update with answers.

Thanks!

David Peden
  • 17,596
  • 6
  • 52
  • 72
  • tl;dr but I'm guessing you'll need to host your apis from `blah/api` and rewrite the URLs to them from `api.blah`. This should allow you to get passed any cross-domain issues with javascript. – M.Babcock Mar 14 '12 at 03:08
  • The API should use the same authentication strategy as the rest of the site. The authorization tokens are written as cookies and should be sent via AJAX (assuming they are written to support subdomains or you host your API as a virtual directory). – Brian Mar 14 '12 at 03:14

2 Answers2

0

If Im following this correctly, you simply need to make sure your Forms Auth cookie is written with no subdomain so it would be: .example.com and if you are using separate servers, you share your machine key across them.

Since forms auth tokens are stateless and nothing is kept on the server side, this should work fine.

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
0

For simplicity and because I decided it was not in my best interest to consume my own public API, I implemented JsonResult actions on a new controller in the existing MVC site. This allowed me to utilize the existing forms authentication and avoid the cross-domain ajax requests.

David Peden
  • 17,596
  • 6
  • 52
  • 72