I have 2 web sites that are published on the same server.The first one was built using web forms and the second one (The CRM) was built using MVC.
In the crm I have a web api controller that adds new order. The access to the controller is only granted for crms admins. Now I need to have the ability to call this controller and add new orer from the first site. I thought about couple of ways that it can be done and I can really use some help to decide what is the best option.
1.Create a wcf communication between them and wrap the controller this controller with intenal access only (From the same computer only)
2.Pass a pre defined token from first site to the crm.
3.Check in the crm controller if the request was made from the same server
4.Create using owin a self hosted web api in the crm , that listens to some localhost port.
5.Any other idea with explanation
Kind regards,
Tal Humy
If they're on the same server, is there an exposed API to the classes themselves? Can you reference your MVC project from your web forms code? Doing this would flatten the communication layer so you wouldn't use up networking resources unnecessarily.
Related
So I was thinking instead of the traditional model:
Create a service
Inject the DBContext in the service
Create a controller, inject the service in the controller
Call the controller method to access the data from the razor component
Since you can inject the service directly in the razor component, why not do that and handle the authorization directly in the service?
Would that cause security issues?
Would it be possible to extract the connection string if the code gets debugged via the browser?
In Razor Components there are two modes of execution: On the client browser (Blazor), and on the server (previously called server-side Blazor). When your app is hosted on the client browser, you can presently access your database only through AJAX; that is HttpClient, which requires you to create a web API project that can access your database (directly or through services and repositories, etc.) and returns required data.
As you can see, though the front end Blazor app is running on the client (C# on the client), you cannot access your database directly as your database resides on the server. Authentication can only be and should be employed on the server, and requires AJAX calls.
When your app is hosted on the server (ASP.NET Core application only), you may employ to methods to access your database. Creating a service that query the database and returns data directly to the calling Components App. This is possible because the Components App project, and the hosting ASP.NET Core application resides on the server. No need for Web API here... However, you can create a Web API which serves the data even in this case. Authentication and Authorization should be the same as in traditional ASP.NET Core Web application.
ASP.NET team has stated that switching from client side Blazor to server side Blazor should be done by modifying a couple of code lines. This is partially true, and can be misleading. You have to design your app from the very beginning based on the mode of execution you expect to use. Personally, I would recommend using Web API in both execution models. So that switching from one mode to another can be as easy as ASP.NET team says. Again, if you create a service that directly accesses your database and returns data to the calling Components App, you cannot run this code in browser mode of execution, as the database is on the server and your service "is running" on the client. So designing your applications and knowing before hand how and where it should be used is of great importance. I'm of the opinion that services instead of Web API should only be used in Intranet applications.
Hope this helps...
I have an ASP.NET Core Web API application that is separate from my ASP.NET Core MVC application (UI). I didn't want to combine them for several reasons since in the future many different clients might need to access the API.
The MVC application makes calls to the API two different ways:
1. Using System.Net.HttpClient in the MVC controllers to populate the View Models.
2. When making jQuery AJAX calls I figured it would be best to directly call the API. (Note: I enabled CORS to allow calls from the MVC application). This would be the same thing as an Angular client making calls directly to the API.
My questions:
Is what I am doing pretty common making calls to the API directly from the client with jQuery and additionally System.Net.HttpClient in the Controllers when not using AJAX and just loading the view data. Should the AJAX calls go to the MVC controller first then let them MVC controller make a DELETE request using System.Net.HttpClient so I am never directly calling the API from the client?
What would the security concerns be? I am a bit nervous calling the API directly from jQuery. I feel like anyone can pretent they are localhost:6000 (my MVC port) and make a DELETE request to localhost:6001/api/users/1 (my API port).
You absolutely correct to be concerned about this. You should be securing your application from this making sure any requests to access these API methods are authorized.
I recommend reading 10 Points to Secure Your ASP.NET MVC Applications. for an overview on how to protect your application from this kind of attack and several other common security vulnerabilities.
I currently have a lot of Web APIs that are being used by various applications. All of the APIs are using ASP.NET Web API 2 with 4.6 .NET framework. I want to be able to keep track of all the different applications that are using a specific API.
Example:
Lets say I have the following API:
Employees API - gets all employee(s)
And I have the following applications that call the Employees API
Employee Management System - located at /intranet/employee/add
Time Off Request Form - located at /intranet/timeoff.aspx
The Employee Management System calls the Employees API using HttpClient in C# code.
The Time Off Request Form calls the Employees API using an ajax call in JavaScript.
I want to keep a log of all the applications that are using a Web API and preferably what action they are calling. What is the best way to achieve this?
Is there a way to get the Callers URI?
From the Web API is it possible to know that /intranet/timeoff.aspx is calling the the add employee action on the Employee API
I believe you have a few options.
Add a header value to identify the application to each request from the applications.
Add a claim identifying the application to a security token
(assuming you are securing the requests).
Add a query parameter for the requesting application to each request.
If you have control of the applications that call your API, then Michael_B
offers some good suggestions. If not then you may need to consider some referring information like IP address - see How to get IpAddress and UserAgent in ASP.NET Web API get methods. However, even then that value may not be the client IP but something in between it and your API.
Nevertheless, since you're using Web API, you might consider running all of the requests through a DelegatingHandler first, write the caller info, etc. to a log from there, then let the request continue to the proper controller. See http://arcware.net/logging-web-api-requests/
I have made a new project using the ASP.NET Web Application template in Visual Studio 2015. Then I selected MVC and Individual User Accounts to specify the template further. The solution I got is complete in that it offers me all the web pages you need for account management such as registering and logging in.
However, now I want to hook in a Xamarin.Forms mobile client to this account management scheme. I am making a native UI to register users, instead of redirecting them to a webpage or webview. I want to send user registration data, such as username and password, from this UI to the server so it will create an account. This means that I don't want to use the webpages offered by my MVC app, but rather send the registration data to the server and have it create an account, notfifying me of succes or failure.
I am anticipating that I would need to either use HTTP POSTs to login and registration endpoints in the AccountController or implement a public API. However, doing a post will return a webpage, and my client is not interested in a webpage.
I think one of the above should be possible to implement quite easily, but I am having a hard time searching for answers or methods, since I don't know how to phrase my problem properly, and with the abundance of guides on MVC, all my results are muddied.
Is my idea of this being possible flawed or have I missed a fundamental concept of MVC? What are the steps I should take in order to make this possible?
One misconception is that doing a POST will return a webpage. You can return any type of content from an MVC controller. But your account registration endpoints should be Web API controllers that return JSON. That JSON can be as simple as containing a boolean that indicates if the action was successful or not.
You do not need to use MVC at all. You can completely do away with the account controllers and views that the template created for you. Just copy the code that you need from the MVC controllers into your Web API methods.
You're right, this is quite easy to do.
I think, You can use ASP.NET Web API for doing this task. On server, you host your API for registering the users as well as logging into some client application.
Now, You need to consume this API in a client application. The client application could be a Console application, Windows application or a Web application. There are lots of tutorials about making an Web API on official ASP.NET site.
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:
Implement services that support the MVC site directly under the /services URI, eschewing consuming my own public API.
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.
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!
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.
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.