i'm testing an API service using OAuth tokens.
we have to divide the load per api service, therefore i seperated all services in different thread groups (also to make requests in parallel). since extracted OAUTH tokens (you need the acces token to make request to api) are only local to thread groups, i used a small beanshell script to write all tokens to a CSV file.
later on, these tokens are used when doing the API calls.
the problem i'm facing is that the 'CSV Dataset Config' element is pre-loaded in memory (correct me if wrong), and because the tokens arent received yet at that point my API calls are failing with regex EOF. this happens only a few times where after the request succeed. i implemented a once only controller for the api requests to implement some thinktime, but this does only helps waiting for all users to get authenticated and receive the tokens.
question 1: how can i read token values in realtime from the CSV file for each api call (using custom code/beanshell)?
question 2: how can i make my beanshell script (see below) REWRITE the whole csv file each time the oauth2 sequence is run (now it keeps on appending to it..) ?
situation:
Issue fixed using 2 seperate testplans;
plan A) do one iteration with X amount of needed concurrent users to generate needed tokens + write tokens to CSV file.
plan B) call all API services divided in Throughput Controllers using CSV dataset (OAUTH sequence not needed).
Related
I'm a new user with SoapUI, but I feel like this process should be easy. I've read all of the documentation I can find on this matter but I can't seem to get around this.
The issue:
I am working on load testing a website for a customer, this will involve creating 1000 accounts and navigating through a course signup process. I've managed to create test cases that step through the creation process for a new user, upon creating the new user the website automatically does an OAuth2 process and redirects the user to their profile. The way this process flows is: account created > credentials sent to a token URI in the REQUEST > RESPONSE kicks back an access token > token is used to grab credentials and redirect user to profile.
I have successfully extracted the token as a variable and stored it to the local test case, however this is where I get stuck. The only way I am able to retrieve the user profile is by manually pasting the access token into the OAuth2 access token field in SoapUI, then running the test case. Since I have to do this with 1000 accounts, this is obviously not an effective method.
I've attempted to grab ElementIDs of the login page/user creation page using the automated access token script editor, but all of these fields are located in a separate .js script, therefore the ElementID doesn't exist in SoapUI.
Am I going about this wrong, or is there someway this can be done? I'm not looking for anyone to write my code, merely explain this process if I'm understanding it incorrectly.
I managed to bypass the OAuth2 Authentication method by creating a Groovy Script that grabs the "Set-Cookie" header from the token call then adds the cookie to each call afterwards.
This method appears to have solved the issue!
import com.eviware.soapui.support.types.StringToStringMap
def getcookie = context.testCase.testSteps["Token"].testRequest.response.responseHeaders["Set-Cookie"][0]
def headers = new StringToStringMap()
headers.put('Cookie', getcookie)
testRunner.testCase.getTestStepByName('Get User').testRequest.setRequestHeaders(headers)
Hello frinds presently i am doing manually authentication and getting user tweets and post form various api like instagram,tweeter,youtube but it requires authentication .
Now i want to automate the process and wish to run cron so i can fetch data every hour with authentication.
I know it is possible by passing access token in url methods but no idea how to do it.
first of all you need to have those access tokens. I'll explain the YouTube API and will also write other API's links. Process is similar in almost every API first you get the token then you pass it in URL.
YouTube API :
Here is a document about YouTube API which will help you create your own access key. After creating it just pass the key in URL with key=YOUR_API_KEY. You can retrieve datas from these links they might also give you an idea about how to use the api key : Videos , Channels (There are examples in the documents for JAVA, PHP and Python ). If you are using PHP you can use this curl function for authentication and retrieving datas.
I've got a Mule application that listens for requests from one application, then responds by calling a JSON API multiple times to authenticate and then retrieve several data, doing some transformation, and returning the results. The API requires HTTP basic authentication. When an account authenticates, the application that provides the API 1) returns a session/authentication cookie that can be used to identify the current user in subsequent calls, and 2) updates the database to record the last authentication timestamp for the current user. The API also has a call to check to see if the session/authentication cookie is still valid.
I currently have a flow that invokes the authentication method, then goes on to make a bunch of calls with the session/authentication cookie.
The issue is when the Mule application gets many requests at once, the application that provides the API deadlocks trying to update the authentication timestamp, since the flow will authenticate once for each request. Is there a way (possibly using the object store) to store the session/authentication cookie for use by subsequent requests to the Mule flow? Basically, I want the flow to suspend all other requests to the same flow, check to see if there are stored cookies, check to see if they are still valid, authenticate (again or for the first time) to get a new session/authentication cookie if needed, store the new cookie, then continue.
Is that a reasonable way of doing that, and is it even possible? If not, I think you can get the gist of what I'm trying to accomplish. What better way is there? Thanks!
edit: I've done a little experimentation, and I can definitely use the object store to hold on to the cookie. The part I'm stuck on now is how I get the only first request to re-authenticate if there is no valid cookie while any near-simultaneous requests wait. I'm looking into VM queues and the Mule Requester, but I'm not sure that that will work. I will post the code for a fully functional test when I'm done.
The title is a bit obscure. I'm interested about some feedbacks on a specific architecture pattern.
Let's take as an example the Stripe API: when you are using this API, the system is basically broken into two parts: live mode and test mode. If you hit the "/customers" end-point, you can either retrieve test mode customers or live mode customers, based on the type of API key used.
I'm asking myself how I could implement such a pattern using an OAuth 2 access token.
In my workflow, I have a single application page (JavaScript) that communicates through my API. I have a "live"/"test" switch, so basically my whole website is replicated into two distinct environments.
When I log in into my application, my authorization server creates a unique access token (OAuth 2 Bearer token), that is send for each requests. But obviously, my access token is tied to the "session", not an "environment" (live or false), so if I want to implement a switch live mode / test mode, I cannot rely on the token, because the token is "generic".
I've thought about two options:
Depending on live mode or test mode, I send an additional header to all my request (like X-Livemode which is either true or false). Then, in my back-end, I reuse this header to automatically adds a filter on all my requests.
If I switch to live mode or test mode, I ask my authorization server another access token. This would means that access token would have additional context information. However this seems a bit complicated, and I'm not sure that OAuth 2 spec allows token to have such additional information.
I'm not sure if this post is clear or not :p.
The second part of the question, is what is the best way to implement such a system where all the resources are basically duplicated between live / test mode ?
In my understand, it should be as simple as adding a "isLivemode" property to all resources, and make sure that all my SQL queries are aware of this. Is this correct?
Thanks!
A much simpler solution I've used in the past (albeit a bit of a workaround) is just to append "live" or "test" (base64 or hex encoded) to the api key, like so:
Imagine your actual key is:
9a0554259914a86fb9e7eb014e4e5d52
In your key presentation, present your key to the user as:
9a0554259914a86fb9e7eb014e4e5d526c697665
Then use a regular expression to strip off the known characters.
Alternatively, if you're equipped to handle key-value maps, a more "OAuth2-spec" approach would be to generate unique keys for live and test and do a key-value map lookup on the request to determine if one belongs to live or test.
I have started to design a RESTful API and I'm thinking about how to handle authentication. I want to use some kind of authentication token but I can't use OAuth o similar infrastructures so I have to handle it myself.
One of the requirements for this API is that it must have good performance, enough to handle a high volume of requests before there is the need to scale; my concern is how to make on each request the time needed to verify the token (integrity, expiration, IP Address, etc...) as little as possibile.
I suppose the token should some kind of hash and not an encrypted string containing the user information because the decryption time would be to heavy.
I've read that I could store the tokens in an in-memory hashtable where the key is the token and the value is the user info needed to process the request, but how can I make this work in a clustered environment where there will be an hashtable on each "node"?
Should I put tokens on a DB table an hit the DB every time also Handling manually the retention of expired tickets?
Probably it's not that important for the question but I'm using Spring MVC for the RESTfull API.
Thanks in advance.
I solved my problem by using both an in-memory cache and a db cache. Here is a summary of my solution that may help anyone with the same task.
the user logs in and in that moment a unique key is generated and sent back to the user.
that login token (which is basically a GUID with some processing) is also store in a db table with additional info like exipiration and with the user's info and roles. the same pieces of information are also store in memory (google guava hashtable where the token is the key)
the token must be passed along with every api call in the authorization token as #ipa suggested
the server code checks if the token is in its memory cache the user info are already available otherwise (e.g. the api call is done on another node in the cluster) the token is search in the token db
once the token is found you can check expiration, roles, etc...
This grants a good level of performance and security, the token can be generated with any arbitrary algorithm even a relative slow one since you don't have to recalculate it on every api call. Also this works with a stateless service wich can be scaled up horizontally.
I assume you use https and therefore all the traffic is encrypted. I'd suggest one of the following principles.
Basic Authentication
You can add the credentials in the Authorization header of the request. This credentials are encoded with Base64 (see below). This credentials could be sent on every request and then checked with your DB. To get this faster and less IO intensive you can still use a cache. Once I implemented an API like this without a cache and was able to handle thousands of requests per second.
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Authorization Token
There are different ways to implement your idea with a token. A common one is that every API user has his own token usually called api key which never expires. Another one is that you first have to authorize (Basic Authentication) and then get a token back which expires. This one is then used as api key for a certain time.
Either way you have to decide whether to use a cache or not. I would keep it simple and go for basic authentication and check the db every time. Almost every framework has very good support for this approach because it's simple http. If this causes performance issues (I'd recommend performance tests anyway) try to add the table with your credentials to the JPA cache. If you want to implement something with expiring tokens have a look at Infinispan.
You can store token in Redis. If you are going to store it in DB, make sure you optimise server (if you are managing it) for read operations. I have couple of implementation where folks have used key value store as well. Hashtable is also good idea.