Unit testing APIs that require OAuth tokens [closed] - c#

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am trying to write a suite of automated integration tests to test my C# client library calls to the Yahoo Fantasy Sports API. Several API calls require OAuth tokens, which is where I am having some difficulty. I can use a web browser to generate an access key and secret and then pass those along in my test code, but the tokens expire after an hour, so I need to manually regenerate these and update my test configuration any time I want to run the tests.
Are there best practices for writing API integration tests when OAuth tokens are required?

normally such api's offer a way to get authentication tokens without the need to use a browser. I am not sure if yahoo sports is one of those though.
Normally you have to create an application to access an OAuth2 system, they then give you a ClientID and ClientSecret, then you hit a token URL and receive the access token which is then valid for an hour.
You might want to consider not having integration tests at all though. If I were you I would simply mock the Api responses and use that in your tests. So, gt a sample of the response for each call and then simply create a fake response which returns that whenever you hit it. you can then still run your tests.
The question you need to answer is this : what exactly am I testing? Are you testing a third party APi or do you want to test your own code.
Also, don't forget each api allows to be hit a certain number of times during a certain time window. One more reason to fake it, I'd say

Related

Having C# API automation tests running during deployment [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 days ago.
Improve this question
I recently moved to a project which is having C# APIs. CI/CD pipeline has been setup for continuous deployment. The project is almost build from past 5+yrs.
The project has a set of API automation tests configured in CI/CD pipeline which will be executed during deployment to validate whether all the APIs are working. If any test fails, API won't get deployed.
Design and content of API automation test:
C# test project using Microsoft Unit testing.
Uses REST client to call APIs for testing.
For each API (GET/POST/PUT/DELETE) a separate test method has been written which will call the actual API using REST client.
The test will call actual API and does database operations (CRUD) which delays execution of test process which in-turn delays deployment.
Doubt:
Is it a good practice / approach to have API tests which is performing CRUD operations by calling each and every API during deployment into various environments?
We have Unit tests for each API where we use MOQ. Unit tests will be executed when we raise PR (pull request) for merging to master. And also we have minimal required integration tests. So, do we need to have a separate API test (that does CRUD operation) during deployment?
We are trying to have best practices in place to avoid blockages / overloading tests during deployment.
Please suggest if there are any best practices related to having different types of tests for C# API projects.
Thanks!!! in advance...

What are the advantages of hosting your API(s) and IdentityServer4 host separately (C#, .NET CORE)? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Perhaps the question I am about to ask is very obvious and simple, but as a beginner in IdentityServer4 and more or less in oAuth2, OpenID and API's in general, I find it quite hard to understand.
Our company's goal is to move to a more secure application building way (Visual Studio 2017, C#, .NET Core 2) using Authentication and Authorization. After some days of research I ended up with using IdentityServer4 (also because the documentation is really great).
After following the IdentityServer Documentation (https://media.readthedocs.org/pdf/identityserver4/release/identityserver4.pdf) up till chapter 7, I have one remaining.
I am trying to build a MVC application (web) with an API backend for retrieving / inserting the data so that I can later use the API for other applications, like a SPA / Xamarin application. For the IdentityServer host I went for IdentityServer with asp.net identity. I got it running and it all works great, however the following question remains:
What are the disadvantages of hosting my API, in which I want to handle Database operations, together with the IdentityServer host?
It doesn't seem logical to me to have so many different projects while (so far as I can tell) these 2 (the API and IdentityServer host) can be joined together perfectly fine.
In (almost) all the examples found of IdentityServer4 the IdentityServer host and API's are separate projects, what are the advantages of hosting the two as separate projects.
I would say Single Responsibility.
Treat it like this - Identity Server is a framework, that provides you the authentication against your clients/API's. That's it! (of course this is all done based on your rules, policies etc).
It is not Identity Servers' purpose to add/edit/delete users from your database. It is not Identity Servers' purpose to give roles to this users.
And most important - it is not Identity Servers' purpose to authorize this users.
All these must be done in your clients/api's.
In your case - you need a separate API that will take care for the users (and other data that you need), but I guess that you want this API to be protected by Identity Server.
This is where the separation comes and should be kept - Identity Server should not authenticate its own API against himself.
There is a reason that all the examples, articles and etc are with separated projects.
PS: Of course there are some examples of achieving this (damienbod's one is good).

.NET Core API Gateway [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've got some work to do for school around Microservices.
I've got the architectural concept, but need an implementation to show off. I'll be using angular2 as a client, would like to use a .NET core API gateway to dispatch my requests to different services.
What's the best approach for this? I red something about using Rx.Net, but no definitive example or implementation that I can follow.
So what should I do to implement an API gateway in .NET Core?
This may or may not help but I am currently building an API gateway in .NET core.
You can find it at https://github.com/TomPallister/Ocelot.
The code is a little ropey but a few people are working on it now so hopefully we can improve it over time.
You want to have a server that listens to the incoming API calls, e.g. a HttpListener.
Inside the handler of incoming requests, you peek into the request and decide where the API call needs to be relayed.
Then you use something like a HttpClient to make another request to the actual API endpoint (mimicking the original request as closely as possible) and you relay its response back to the user.
It should all be in the listener's request handler, and the response to the original request is the response from the real API.
See MSDN docs on HttpListener.
Also a good read: Handling multiple requests with C# HttpListener

Restful service with WebAPI and MVC as client architecture [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am building a restful web service api using ASP.NET WebAPI. I'll be consuming it with MVC as a web application and eventually in a mobile app. I want to make the api standalone and not couple it with the MVC application.
I am having trouble figuring out how the authentication should be structured. I need the api to be consumable only from a specific sources(the web app and the mobile app). However, I dont know how to link the authentication in the WebAPI with the MVC one. New users should register in the MVC and their auth info should be supplied to the WebAPI. I'm using the Individual accounts Identity system for the project.
In short, how to use the same authentication for both the Api and the Client? Should they be deployed to the same domain?
I recently did something similar.
I think you have 2 issues here:
You want to only accept Web API requests from known sources.
You want to authenticate the user.
For number 1:
You want to add authentication to the Web API Request. This could be basic authentication, but it shows the call is coming from a known application. By using this, you know where the call is coming from. Despite what you read, Basic Authentication is ok, but only if the call is over a TLS (HTTPS) connection . Otherwise the call could be seen and the authentication could be used in a replay attack.
For number 2:
You could have a method that the user can call, such as a login request, where the user can be authenticated and, if successful, issue them with a token. JWTs (Javascript Web Tokens) are one token that you can use. Then the token can be sent with each subsequent call. However, please bear in mind that they can be a pain to use!
It depends on how tight your security needs to be. It might be that basic authentication, along with TLS might be enough for you.

Onedrive wcf web service [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Hi I'm developing a wcf web service that integrates with OneDrive and I need to access to the files (list, delete, download and upload) of the users that use my web service.
Is there a way to use Onedrive in an easy way? maybe some C# API...
I found the Live SDK but I can't understand how to use it, then there is SkyNet but I don't know how to use it and if it works with OneDrive.
In case I would have to use REST calls, can you explain how to authenticate and list file with REST?
thank you all
The main challenge you'll have with writing a WCF service is doing authentication. I'm not aware of a straightforward way to proxy authentication with your WCF service into the OneDrive service. The easiest approach would be to have the caller of the WCF service handle generating the auth token (see the examples for how to generate an auth token in the OAuth reference) and pass it to your service as one of the call parameters.
After that, you can use the Live SDK to make server-side calls using the token provided to your service from the caller as a parameter to your WCF method. You can either use the Live SDK to generate those calls, or you can make them yourself following the REST reference. Neither give you an object model that you can interact with, you'll need to understand how the REST service works and the structure of the returned JSON data to use the Live SDK.

Categories