I am performing API testing using Jmeter, we have a API request which require authentication.
When I make a call http://localhost:3001/city/latitude/longitude (GET method) it returns User is not authorized. And to get authorization you require to call http://localhost:3001/user (POST method) passing username in json format.
So, how can I make a authorized call on http://localhost:3001/city/latitude/longitude
It really depends on your app, but usually algorithm is like this:
Call authentication method, in your case -
http://localhost:3001/user (POST method) passing username in json
format
It will return some sort of authentication token as either a cookie (more common), or in the header, or as a response.
You pass said authentication token with each following request. In case of a cookie, all you need is HTTP Cookie Manager. In case that token is returned in the header or as a response, you would need to extract it, save it as variable and then pass to each following request (of course you need to find out what is the name of the parameter or header to pass it as).
Related
I'm building out a backend REST API app, and it takes in requests from a client that uses Firebase Authentication, which will be passing in the JWT Token in the headers of all requests.
Should I still require UserID in the request body for requests, or should I just have the JWT Token be my source for decoding and fetching the UserID for all requests?
Using SpringBoot, and I think I can create a filter to decode the JWT for all requests and then create a User object that can be referenced throughout the chain.
But I'm not sure if it still makes sense to also require the UserID, if anything just as a point of documentation to say the UserID is being used here to handle business logic. Watcha think?
I don't think this would make any sense. You wouldn't actually use the value from the request body anywhere in the code, would you? Since your concern seems to be abobut documentation I'd rather clearly describe that resources in your application are bound to the authenticated user.
I used Laravel-8 for rest api. The route is shown below:
localhost:8888/myapp/server/api/v1/admin/role
It is a GET Request.
When I send it on POSTMAN, I got this error:
401Unauthorized
{
"message": "Unauthenticated."
}
In my route I have:
'middleware' => ['auth:api']]
The reason is because I don't know how to add the Login details. email: akwetey#gmail.com, password: mypass
How do I achieve this?
Thanks
This person walks you through the process nicely and should get you setup.
https://coding-lesson.com/api-authentication-with-laravel-passport/
Basically you need to:
Get to your login api, probably something like: localhost:8888/myapp/server/api/v1/login
Create a POST request to the login API, select the Body tab and define key values for you Email and Password
Then run the request and copy the AccessToken value from the results
Now with your API above, select the Authorization tab, choose Bearer Token as the Type and paste in your AccessToken value for the Token field
You should also go to your Headers table and define Accept and Content-Type keys, both with values of: application/json
Of course you'll want to then change all this to use variables after you get it right, so you don't have to keep repeating this with all your new API calls.
To fetch data behind protected routes you need to provide a token that will verify that the user who made the call is authenticated.
Then you have to provide the token in Authorization section of postman.
I assume you know the difference between Post and Get. Laravel works a little different then regular PHP, let me tell you how.
In order to access the protected routes you'll have to first access the token from login route. By sending the required data in .
Once that's done it'll return the token which can be used to access the protected routes under admin or auth middleware.
In your case you're accessing localhost:8888/myapp/server/api/v1/admin/role which is a protected route under admin middleware. You'll have to first access token and then send token with the get request to fetch the required data.
I have the following route in my routes/api.php
Route::get('/games/{game}', 'GamesController#show')->name('api.games.show');
On client side, I already included Authorization bearer token header in every AJAX request.
How can I retrieve the value of the user associated with the token throught $request->user() without having to require authentication (without having to use ->middleware('auth:api'))
Basically what I want is to have one route that serves for both authenticated (with token) and non authenticated (without token) requests.
I want to know if it is possible to implement some interceptor to check user authentication in websocket RPC.
My use case is
User registers himself with some token using URI 'com.safe.reg'
Token is validated and cached against the sessionid
For next call to some other URI (say 'com.bus.op1') I want to ensure that the token is still valid and hence want to call something which will check the cached token for the sessionid.
I want this to happen for every business call and also, I don't want to send the session id as parameter in the function call.
This is typically handled in the interceptors in http request-response communication. How can we achieve this in websockets while using crossbar?
I am making an ajax call from my client to the google oauth 2 API 'https://accounts.google.com/o/oauth2/auth?redirect_uri=http://blah.com&response_type=token&client_id....' to get the access token, but i get following error:
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://blah-blah.com' is therefore not allowed
access
I want the call to be ajax so that the user is not disturbed when the call is made through url or window.location.href or in other words, how can i get the access token such that the whole page does not load, and is it possible to resolve the above error???
OAuth2 auth endpoint doesn't support AJAX by design. It's an entry point to the authentication system, so you must get there by redirect. The result of the authentication is again a redirect to the URL you provide, so AJAX doesn't make much sense there.