How to automate Rest API which require authentication using Rest assured - rest

I want to test a Rest API which require authentication, before getting the Json response. FOr exa. If i want to visit rest API:
then
if I am not already logged in , then this will redirect me to Login HTML page, and after login, this will show me the Json output.
Now I want to write a Rest assured code in java for same: I dont know , whether this is possible to do login using this or not.
Steps :
Step 1: When you send a request to the API, This will redirect to the login html page.
Step 2: Enter username and password in the page.
Step 3: Then we will able to see the response.

if your ui is spa you must use JWT for auth. and therefore you must send TOKEN in every reuest to server.
otherwise if use mvc ForEx SessionBase Auth handle this problem.

Related

How to set a authenticated user web session for sending rest requests

I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).

What is the correct workflow for auth to a web site which uses a REST api

I have a web site written in Angular that uses a REST api in order to provide functionality.
I would like to know the proper workflow for authentication to the website.
Let's go back to 1999 - I write a website and all the logic is in the web code. There is no REST API. If someone wants to log in to the website they enter their email and password and I store a cookie on their machine and they now have a 'logged-in' session on my website. By having this cookie they are authorized to do certain things such as write a comment.
All good.
Fast-forward to my new website. This website is written in Angular and all content is provided via a REST API. Some of the REST calls just display data like a bunch of comments. Any anonymous user can make these calls just by browsing the page. However, there the user can log in to the website using their email and password. Again, I store a cookie on the user's machine and they are logged in to the website. Now, because they are logged in to the website they can post comments. These posts are done via a REST API call. However, Google and the Interweb have told me that my REST API should be stateless and i should be using oauth2 for this request.
My question is, what is the workflow for this very common auth pattern?
I thought maybe something like:
User logs in with username and password
One request is sent to my web auth server and a session cookie is created
A second request is sent to my api auth server which issues a valid token for further requests
The two systems are quite separate and do not depend on each other.
If i was to add social login to the mix then (2) above would just be authentication to the required social auth server and (3) would be unchanged.
Yes, your REST API should be stateless.
This is a typical workflow for authentication for a REST API.
User logs in with username and password.
A JSON web token is issued upon login from the backend and sent to the browser.
The JWT(JSON web token) can be stored in a cookie in the Web Storage(local/Session Storage) on the browser.
Subsequent requests to the REST API will have the token embedded in the header or query string for authorization. With that form of authorization, your REST API understands who is making the request and what kind of resource to return based on the level of authorization
A practical example of this can be found in this blog post. Angular 2 was used for the sample app implementation.
I hope this helps!

Authorization process in BoxAPI

I'm new to the Oauth2 autentication process and i'm a bit stuck cause i would like to use Zend Framework OAuth module to connect to Box.com API.
I've found an example to connect to an Oauth service with zend framework and i've followed some tutorial on youtube about the oauth service, and for what i've understood i've at first to connect to the authorization process (with the client_id the response url and the response_type set to "code"). That's what i've learned from the tutorial. But in the developer part of the www.box.com site there is a strange parameter to make the GET call and try to authorize the application to access the user content:
https://www.box.com/api/oauth2/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&state=security_token%3DKnhMJatFipTAnM0nHlZA
The parameter "state" has to be updated with information on the application or it has to be left as it is in the online tutorial? I'm a bit confused.
The state parameter is optional. It is intended to provide an additional layer of security for your application.
Consider the OAuth workflow:
Your application redirects the user to Box.com
Box prompts the user for credentials and authorization
Box redirects the user back to your application with authorization information in tow.
The state that you send to Box in Step 1 is sent back unchanged to your application by Box in Step 3. Your application can compare these values to verify that the Box redirect in step 3 originated from a request made by your application.
The state can be any arbitrary string. Pick a random string of some length. This value should be generated new for each new OAuth request (i.e., Step 1), since it's intended to identify a single OAuth cycle for a particular user.
Does that make sense?

REST API and client on same server, need API authentication?

First, let me describe the application: we are working on a web-based software which is some kind of custom help desk application. It requires the user to login (we use FOSUserBundle). After login the user is redirected to the dashboard. From the dashboard there is no more page reload, the frontend is build on Angularjs and the user can get anywhere within the application without page reload. You could speak of a single page application.
So the data that is presented to the user, is fetched from a rest api (we use FOSRestBundle). This works quite well at this point.
There is some kind of dilemma. Only our staff will access this application (for now). So a staff member needs to login to access the helpdesk. The data that is pushed to the frontend via angularjs is called via api, so the user that has just logged in needs to authenticate again on every request because of rest.
Problem: Since the backend runs on symfony2 let us just try to get the user object of the currently logged in user when an api call is made:
$this->get('security.context')->getToken()->getUser()
returns anon. that stands for anonymous, or
$this->getUser();
returns just null.
So the authenticated context seems to be gone when using the rest api. However when I call an action directly without rest, I can get user information.
So what we need is to secure our rest api and get user information on every api call. We don't want third party people to access our application, just staff. I am not familar with OAuth, but the user will be redirected to a third party page to Allow/Deny access to his data? This would not be an option for us.
Based on that information, do you have any suggestions or ideas how to secure the api and transport the user data so that getUser does not return null or anon. but the actuall logged in user?
there's another way to resolve your problem.
It's by using Certificates.
you can generate certificates then use Http tunneling (https obviousley), the server will ask for a certificate (you've to configure Apache for that but it's not a big challenge).
with this in place, you've to add a CertificateManageron the server side to ensure that the certificate is valid and to know who's calling the service (to be able to authenticate the user at each request), the CertificateManager(or what ever you'll call it) will probably have to be configured within you filters chaine (as known in the java world), et voilà
Hop that help you,
Abderrazak
REST is stateless so you will have to send some kind of authentication/authorization in each request. You can use HTTP BASIC AUTH or something like OAuth.
Have a look at https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
I'm kind of building our application in exactly the same architecture (RESTful API with Symfony2 back-end and AngularJS frontend.
Another way is to duplicate the api routes, so that you have the api routes protected by OAUTH and the api routes protected by the session, both of them pointing to the same controllers. The method was explained here: https://stackoverflow.com/a/22964736/435026

Rest Web service Implementation with ZEND

I need to develop a REST Web Service using ZEND Framework. I am new to this area. I would like to know how can I authenticate user's requests to my web service. Assume I am giving a token to all the people who use my web service. I can ask them to pass the token on every request. But Please suggest me if there and standard / better way to implement authentication for REST web service.
Thank you.
Prasad
I usually include the token in the http header with each request then on the server parse the header and validate the token.
X-Authorization-Token: <some hash value>
It's also completely acceptable to do as you are suggesting and require the user to send the token as part of the GET/POST/PUT/DELETE request as you would with a standard page. I have seen others put the value in a COOKIE as well.