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/
Related
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.
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.
I am trying to develop a single page application.
I have built a RESTful web service using ASP.NET Web API. I have implemented authentication using OAuth 2.0 and Bearer access tokens.
This web service uses memcached and HTTP cache headers (Cache-Control and ETag) for caching the resources and responses.
Now, I really like ASP.NET MVC technology and maybe that love is making me use it when I shouldn't.
I'm thinking of builidng an MVC intermediate server between my JavaScript application and my Web service.
The MVC site would redirect (or delegate) its requests, to the Web Service.
I see many advantages using this approach:
I can store my consumer key (used for authentication) in a secure location, as opposed to storing it in the JavaScript application directly.
I can provide cookies to my JavaScript application, something that my REST web service does not support (because I think it ruins the whole "stateless" and "Pure HTTP" concept.
It would be very easy for me to provide globalization (localization) to my views. I really like ASP.NET MVC globalization framework and I would not know how to add this feature if I plan to create a standalone site.
I can encrypt my access token cookie, and decrypt it on the server, forcing my user to use my MVC proxy to access the web service, as he will not know his access token.
Having stated these advantages, would it be worth it to implement this?
Adding a proxy server will made me replicate the HTTP cache logic, and will also end up creating 2 requests (Client -> MVC -> Web API) instead of 1 (Client -> Web API).
What is the best approach?
It looks like you've built a good RESTful web service, but need to address Auth and Globalization:
Auth
Having this kind of proxy or support cookie authentication on the Web API will make you vulnerable to CSRF attacks, so you would also need to implement Synchronizer Token Pattern or some other technique to prevent this. However you should only use this approach if you have no other options, but you have!
Assuming javascript application requires user to enter credentials, there are different ways to deal with auth for it:
OAuth2 Resource Owner Password Credentials Grant
JSON Web Tokens - see accompanying website and a specification
Both ways provide your JS app with an encrypted token that it should pass with each call to protected API. Your application would need to keep this token in a local storage and refresh it when token expires.
Globalization
Even having most of the things on MVC side, eventually you would still require Web API to deliver translated content. So I'm not sure what are the requirements here, but generally speaking you should be able to get your translated resources on Web API the same way. See here for example.
For the HTML part - leave it to ASP.NET MVC, no need to put every label translation into API.
Another points to consider
Performance - ASP.NET MVC is good, but it's not a proxy solution and it's simply not intended to build things like that
Do you really need an HTTP API?
Don't forget that transferring data over HTTP is another point of overhead, and it becomes especially useless if you proxy it with and MVC.
At the end of the day - why would you build an API if you are hiding it from your own application?
My answer is: don't hide it - make full use of it!
I have a project which uses both Web Api and MVC. The authentication is handled by FormsAuthentication, which creates a cookie containing some data regarding the user.
I have extended System.Web.Mvc.AuthorizeAttribute and added it to every MVC controller. What it does is extend AuthorizeCore and check to content of the cookie, which is my own extension of IPrinciple, for wether the user currently has limited access.
I would like to do a similar check for calls to my Web Api, so i have made an extension for System.Web.Http.AuthorizeAttribute which overrides the IsAuthorized method.
In this method i would like to make the same check as for the controller, but i don't know how to get the information from the cookie or if this is even the proper way to do this.
In general using cookie authentication in web api is not recommended.
The reason is that cookies are handled well only in browsers The whole concept of web api is to allow other clients (native clients, java script ...) to use it as well.
If you sure that your server is going to be accessed from browser only maybe you should move your api actions to MVC project (it could return json / xml as well). This way you will not have to deal with those kind of issues.
For web api I would recommend using token based authentication
I have coded a C# MVC5 Internet application and I have a Web API 2 web service that returns JSON data. I am retrieving this JSON data in an android application.
How can I add a feature to the web service such that only my android application can retrieve the JSON data? I am wanting to do this so that other web users cannot hammer the url and the web service will not send my data to unwanted applications and/or users.
Is this possible? If so, how should I do this?
Thanks in advance.
You have various ways to achieve this in fact.
For example, you can store a key in your android application and use send this key together with the request to your WebAPI. Your webAPI will than check if they key is valid and if it is, it will return the JSon.
However, there's no way to ensure that nobody else can request and get your data. For example by reverse engineering your android application and extracting the key, or by monitoring the network traffic and find the key in there.
You need to understand that there isn't anthing that guarantuees you 100% security.
See it as the following:
You have an open door right now, you can close it little by little, but closing and locking down is not possible. There will always be gap. A house also can't by made burglar proof, but you can make it very hard for a buglar to enter.
Go to this link Web Api. I have used the individual authentication for my web api. When you will register the user the response you will get is access token and use that access token as Authentication header in your ajax call if you are using Jquery ajax to call your Web Api. Refer this The OAuth 2.0 Authorization Framework. Hope this help you.
Are you looking for something like this?
http://httpd.apache.org/docs/2.2/howto/access.html
If you have other web server, there should be appropriate means to support such.