I have two servers - web and app. The web server (IIS) serves only static files - HTML/CSS/JS. On executing the JS, the client gets the data from the app server (HTTP service using Web API, self hosted with OWIN). I need to bring in authentication so that my data as well as the content is restricted.
I can use SSL, I can pass username / password to the web api, have it authenticated and get back a token. I can pass this token for future web api requests. In my client app javascript (done using AngularJS), I can also maintain info whether the user is authenticated, what roles she has etc. (for user experience). But for security, I need to be able to ensure the html content requested (in the web server) is also having authentication and authorization done. How can I achieve this?
Should I change my app to make the web server call the app server internally rather than from the client? I can use MVC controllers or ASP.NET, but since I was using AngularJS, I thought it is not required, and is kind of a duplicate. Should I ditch pure .html files and move to .cshtml?
How is this done in the Angular + .NET world, when you data comes from a different server than your htmls?
We've been using JSONP with REST type api to do cross domain AJAX calls, but our Angular client code is within .cshtml files in a .NET project. Sounds like the simplest solution is to use the app server internally- I would go with that
Related
i'm new to asp.net web api, owin, and everything related to it.
I'm trying to find the best way to do this scenario:
1 - Web api to have all the connections and rest service
2 - Web site to show data to user on a browser using the restful service
3 - An mobile app that have some functionalities like the web site and access the restful service to get all the information
My doubt is: what's the best practice related to the login? I'll use owin/oath2 with Identity to login, but since it's going to be implemented on the web api, the login/register/forgot password should be on the web api directly (like the project template does) or should i move most of the functionality to the web site? Of course its easier to leave in the web api, but if i do it, i must duplicate my razor templates just to call the login part. Can someone give me a path to follow?
Thanks!
the answer is not, your web api should not have any html or js or css file, only the services that your need, the web api exposes the functions to register the user, next when you have to do request, you must Send a token, you can obtain the token using the URL that you have configure in owin, the URL is like /token and Send the username and pass.
Regards,
or must it be on the same server as the app calling it? I am new to web api so i am going through some tutorials, but they all assume the web api is part of the mvc app. Also, they show the calls to the api being done with javascript, but I want to make the calls in my MVC app controller. Is this possible?
You can host a Web API anywhere.
The only special thing to have into account when the Web API isn't in the same server that a web site that uses it, is that, by default, the Web API doesn't accept requests from a different domain. For example, if the web site is in "server1.com" and the Web API in "server2.com", then the calls to the Web API from the web server will be rejected.
If this is the case, you need to configure the Web API server to enable CORS (cross origin resource sharing), so that it accepts requests from a different domain. If you want more info about this, please look at this document:
Enabling Cross-Origin Requests in ASP.NET Web API 2
The Web Api can live wherever you want it to. Is typical to see a limited API used mostly to handle AJAX for the MVC application live with the MVC application, mostly because it makes it simpler to construct URLs to the endpoints. If you host the Web Api externally, then you'll have to hardcode the API endpoint URLs, as there's no way to use something like Url.Action to generate them automatically, any more. Regardless, it's a perfectly acceptable way to handle things.
You will probably at least want to add the base URL for the Web Api as an app setting in your Web.config, though. That way, you don't end up with hardcoded references to a particular domain strewn all about your app. That makes moving your Web Api to a different domain much easier, especially when talking about going from development to production.
It is also entirely possible to use a Web Api within your actual controller actions. You'll just need to use something like HttpClient to connect to it and issue requests.
I'm developing a service that has two components - a web interface and a REST API. I use ASP.NET MVC and ASP.NET Web API, respectively. The two components are hosted on different subdomains of the same domain.
I want the REST API to be used by both external users and the web interface, and I want to simplify authentication as much as possible.
The REST API currently only supports basic authentication.
The web interface uses forms authentication and thus generates an ASPXAUTH cookie. The web interface interacts with the REST API using AJAX calls.
My question to the community is:
How do I authenticate the AJAX calls from the web interface to the
REST API, using the most elegant and secure method?
Some ideas:
Send the ASPXAUTH cookie in the ajax calls (by changing the cookie domain to ".myservice.com" to allow cross-subdomain read) and adding an authentication method in the API that reads the ASPXAUTH. Not sure if this is a great idea, or how to implement this.
Storing the user name and API key in separate cookies. Not really safe unless the values are encrypted/hashed.
Using OAuth in the web interface and rest api, instead of forms + basic authentication?
Ok, I've come up with the following solution:
I've added form authentication to the REST API and made sure not to use IsolateApps in the <machinekey>section of machine.config. This ensures that the REST API can use the same ASPXAUTH cookie. I'm making sure to fall back to basic authentication if no ASPXAUTH cookie is present.
Since there's no way to include the ASPXAUTH cookie in ajax requests to a different subdomain due to the Same-origin policy (even though the cookie's domain is ".myservice.com"), the solution I chose was to add an application (through IIS) to the web interface with the name "api".
The ajax calls now point to "/app.myservice.com/api/..." instead of "https://api.myservice.com/...", and the ASPXAUTH cookie is included and works.
Not sure if this is the best solution, but it's both clean and secure. Only tweak is the sharing of machine keys. If running in a web farm you would need to set the same machine key to all machines.
I have this MVC web application that generates and return XML file as a result. I also have mobile application that gets xml file from MVC web application.
I have simplemembership as authentication for mvc web app and I want to use it with my mobile application without using web browser. How do I approach to implement such process?
One approach is to use basic authentication where you send the credentials in the header of the HTML request. You need to use SSL/HTTPS on the server to make this secure. Here is an article on how to use basic authentication with SimpleMembership.
I am making a web application, in which i need to scrape the web to get some data. I can't see a way to do this without using the dart:io.HttpConnection which is not imporatble for web apps. What should i do, Can i make a server application and then use it with a client version, or something else?
You would need to build this server side since the browser security model does not allow you to connect to other origins than the one that served your application (unless of cause you can use JSONP or CORS to do the scraping but I doubt that). So you need to create a service on your server that uses HttpClient to do the scraping for you and then call this service from your client using XMLHttpRequest