Good old Microsoft documentation at it's finest. Does anyone know of any resources that explains how to deploy Web Api with Asp.net Web Forms application. I have the web api in a separate class library and I call using jquery. I don't want anonymous users to be able to access this service only the application. Do I want to use self hosted? How do I lock the service down? Awesome examples showing how to use, tons of videos but nothing on deployment.
You don't have the right architecture for what you are describing, but what you have is right.
If you are calling web services from the client side (using jquery) then your web service must be public facing.
What you are describing is a web or WCF service in a service oriented architecture. That service would most likely live on a different server and be on an internal network, etc. Even if it's on the same server your requirement is that it is not publicly accessible - thus none of your jquery would work since that request is being initiated by the user and users can only make requests to public facing services.
The comments about using forms authentication to protect your service calls are right. jQuery will include the forms authentication cookie for you when it makes AJAX calls so you shouldn't have to change much on the client side.
Related
I have a website written in ASP.NET WebForms, which accesses web services that are written in ASP.NET WebAPI. For security, I closed port 8079 (web services) so that web services could only be accessed via the website, but that it would not be possible to request web services directly from the Internet. When I request a page on a website, through the Fiddler program, I see a request for a website, but I don’t see a request from a website for web services. Everything works well. But now I have made another website written in AngularJS and I want this website to also access my closed web services. Is this possible through AngularJS? Below is the request code for web services via ASP.NET website.
HttpResponseMessage response =
client.GetAsync("http://localhost:8079/api/values/5").Result;
if (response.IsSuccessStatusCode)
{
Task<string> data = response.Content.ReadAsStringAsync();
result += data.Result;
}
As a result, the site(AngularJS) and ASP.Net MVC Web Application should be available on the Internet, and web services (ASP.NET WebAPI) should not be available on the Internet.
Currently, the client accesses the web services directly, but it’s necessary to make the client access the web server and the web server access the web services
Even if you create another ASP.NET app (a kind of 'facade') that handles requests from the client, and invokes web services internally, this alone won't solve the problem:
If the facade accepts requests from any client and just sends them to the web services, it is not different from exposing the web services directly to the internet.
As #Andrei Dragotoniu pointed out, you have to secure your services by only accepting requests from authorized clients.
How to authorize access to web services
A common way of securing access to web services is JSON Web Token (JWT). The token contains encrypted claims that explain the identity (and maybe other aspects) of the client. Typically it works as follows:
A new token is generated on the server upon successful authentication of the client. The authentication can be either manual (a login form), or automatic (for example, with OAuth).
Once the token is generated, it is returned to the client. The client then starts attaching the token as an HTTP header to every request it sends to the web services. On every request, the web services validate the attached token.
This blogpost provides more information and examples of using JWT in C#.
API Gateways
The requirement of limiting access to web services to an internal network is not uncommon. A typical solution here is API Gateway.
(from Wikipedia) Gateway: a server that acts as an API front-end, receives API requests, enforces throttling and security policies, passes requests to the back-end service and then passes the response back to the requester. A gateway often includes a transformation engine to orchestrate and modify the requests and responses on the fly. A gateway can also provide functionality such as collecting analytics data and providing caching. The gateway can provide functionality to support authentication, authorization, security, audit and regulatory compliance.
More on API Gateways in this article. One of the most popular API Gateways is Kong.
Even if you deploy your web service in intranet, you cannot consume the web service from client browser (Angular or JS Applications).
One possible solution could be,
Deploy the web service in intranet web server.
Create a proxy web service in the edge server (they are both intranet & internet facing). Proxy web service should just expose the required methods by obscuring the original web methods.
Consume proxy web service from client-side applications.
Otherwise, client-side applications can never consume the intranet web services.
Optionally, if you create NodeJS, ASP.Net based web applications, it can be deployed on edge web servers that can talk to intranet web services and users (living in the internet) cannot access web services directly.
UPDATE:
Moreover, based on your code above, it looks like you are trying to consume web service from .Net Runtime Managed Code (ASP.Net MVC). Well, in that case, AngularJS will ajax to your controller-action. Then controller, in the edge server, can talk to any intranet web service. AngularJS need not talk to Web Service. It is straight-forward now.
"When I request a page on a website, through the Fiddler program, I see a request for a website, but I don’t see a request from a website for web services"
That statement is true in a very limited context, but the reality is much bigger than that.
The requests from a website to its own API can easily be seen by using browser tools for example ... hit F12 in any browser and look under the Network tab, this is something anyone can do to see what a website ( any website ) is doing.
You need to protect your API somehow. You can use something like OAuth2 or you could do it at server level. You can lock down a server to only accept connections from your website's IP address for example. You can also make it so that the server the API is on is completely locked down. You can lock down the API.
You just need to realize that you do have a security issue if you don't do something. The tech stack you use is irrelevant for this.
We are starting a project which will consist in:
Web project (ASP.NET MVC)
IOS app
and both will consume data from a .NET WEB API service.
The WEB API service will expose a POST Method with the url "user/create". But i don't know how can i avoid another apps for making post to this url? I know i need a security protocol, but i wanted to know which one you recommend me, and if you have, an article where is it explained.
Thanks
web api 2 provides oauth authentication. You will need to get a token from the token end point of web api and pass that token in subsequent requests.
You should find lot of online resources if you search for web api 2 oauth.
We did something similar recently using OWIN OAuth 2.0 Authorization Server
Reference this ASP.NET page for details. Sample code is included as well for several different implementations.
For our purposes, we used the Client Credentials Grant section about half-way down the page. Our implementation involved server-server OAuth (Web API to MVC), but I bet it's pretty similar to have iOS connect. The only thing I would caution is to somehow encrypt the login credentials on the iOS side, and I'm sure there is a way to do that.
So you want the WebAPI to only be used by the MVC page? The best architectural method is to separate the two rather than leave both in one project. Why? Because the MVC app is a experience layer for humans. The WebAPI is an experience layer for the MVC app. Move it back where it can't be accessed.
You can add on tokens, etc, but the MVC app sits on the server, but is accessed on the client computer. The wider the scope of the application (ie, intranet or internet or something in between?), the more difficult the problem and the harder it is for your users to access the application. Moving the WebAPI internal and leaving the MVC app exposed guarantees external users cannot use the API.
The main reason WebAPI and MVC exist together in a single project (still a mistake in most instances, IMO) is you are exposing both to the same audience. If that is not your intent, don't do it.
I'm building a messaging application that needs to receive messages from the web. Originally I was going to run this application as a Windows service and have a web wrapper using ASP.NET MVC that could be accessed by clients to send messages to the application. But I am now learning about the Web API which is much better suited for this task but the question remains whether it makes more sense to include the base application as part of the Web API self-host framework or if I should leave it as a Windows service and wrap a Web API application around it.
Is there really a difference? Was the Web API designed to combine the concept of a service layer and a web interface into a single framework? I'm not sure how scalable/robust a self-hosted application can be compared to a Windows service. Will the Web API self-host method limit me in any way that the service method won't? What about a Web API application hosted inside IIS such that my base application will be running inside IIS? I'm not sure of the specifics of performance that I need (such as memory or CPU) at this point so would it be easier to start with IIS and then if needed, convert it into a self-hosted/windows service if the need be? I hope these questions make sense (although I'm not sure if they do).
I'm new to Web API so I'm just trying to wrap my head around these concepts.
I currently have a MVC application that is using Forms Authentication. I realize that you cannot self host a MVC application. Business requirements dictate that my application has to be self hosted. I was thinking of creating either a WCF or Web API application that is self hosted, where I can expose various endpoints. However, the problem I am facing has to do with authentication. In my MVC, I used Forms Auth, and allowed the user to use a form to enter credentials. How can I do something similar in WCF or Web API. I know how to render the HTML for the login page, etc, but the part that I am not familiar with is how to code up the smarts that anyone who tries to access one of my endpoints needs to be redirected to another service, so that I can do my thing to authenticate them.
I guess I'm trying to do something similar to the Forms Authentication redirect, but, within the context of WCF or Web API. I started looking into message interceptors and route filters, but, still need to do some research.
Any ideas to point me in the right direction ?
Forms Authentication Control Flow is explained here. This is what you need to implement using a DelegatingHandler for ASP.NET Web API.
I am starting development of the new project and since I am new in the WCF world I want to ask your advice.
I am going to implement web-service which will provide data for WPF client and for ASP.NET site. Web site and web service should be hosted in the Windows share hosting (not didicated server) and this fact is bothering me. WPF client and web site will provide almost the same functionality for the user, so I want to implement all logic inside web service not to duplicate it in the client and web site.
Not sure what is the best way to implement such web-service - REST, SOAP or something else? Please, help me with selecting technology for web-service creation, I just want to get direction for optimal solution. 10x.
Update: Sorry I did not wrote details. Service will be something like on-line shop with admin panel, so web service will be used for getting products and for adding new product to the system. It does not support tons of customers, it's just solution for small web-shops.
since you are developing a Web based solution and a WPF client, i would recommend the following options for your WCF services:
REST Option - This option is good if you have some complex Ajax architecture on the client using Json and stuff, or if you want to expose your services publicly. In this case the option is to expose an HTTP endpoint using webHttpBinding on your service. Since your deployment will be on a shared web server, you can host your service inside IIS. I would recommend considering a SSL option for security.
Soap Option - This options is the easy one, and should be more familiar to most developers, since it acts like a usual web service. In this case i would use an HTTP endpoint with wsHttpBinding on the service for enhanced security. Since your deployment will be on a shared web server, you can host your service inside IIS. I would recommend considering a SSL option for security.
Whatever solution you choose you will be able to accomplish your goal to have simple SOA architecture in place and will have centralized services for your CRUD operations.
I hope this answered your question.