Identify the correct HTTP method - web-services

I have created a REST web-service using springboot. It has users resoruce for below urls
/users => get the users in system.(GET)
/adduser => Post a new user.(POST)
/addFriend/{friendID} => this method is to add the friendID into the current logged-in friend(the user resource has friend list) now my doubt its Its a POST request of a GET request. Currently GET method has solved my problem. But I am not sure about the correct method which is right one logically.

No, Restful API targets resources and does not contain actions in the URI.
Example:
GET /users
=> get user list
GET /users/:userid
=> get info of a user via userid
POST /users
=> create a new user
DELETE /users/:userid
=> delete a user via userid
POST /users/:userid/friends
=>create a friendship and you can send body include ID of another user.(JSON/XML)
GET /users/:userid/friends/:friendid
=> check friend between two user maybe return friendshipID or true/false

It is a POST Request.
According to Wikipedia:
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect.
and
The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.

Related

How to get payment response from paypal as boolean in django?

I am using Paypal api for my Django website.I am able to make payment but don't know how to get payment response from paypal server as either True or False.
Without knowing what you are currently doing, I can only share the best solution.
Create two routes, one for 'Create Order' and 'Capture Order', documented here. These routes should return/output only JSON data (no HTML or text).
Pair those two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
In the Capture Order route, before returning the JSON, examine the response for a PayPal transaction ID in the payments object and store this information in your database. If there is a new transaction ID, its status should be 'COMPLETED' or 'PENDING'. In the latter case, flag it for manual review in PayPal.com

In Postman Test script Can we execute another request in collection

In collection I have 5 requests. In one of a request I want to script in Test tab that after getting a response to execute a request already in the collection.
I cant find references/blogs/article for accessing requests in collection. Alternatively I can write a request. But I need to set authorization logic, and other settings.
Use the below script in the request from where you want to trigger the next request.
Note that request names has to be unique in a collection.
Refer this link for more details
postman.setNextRequest("Request Name")
Update
If you want to send a request after a single request is run, use
pm.sendRequest()
Refer this for pm.sendRequest
Note that pm.sendRequest has to include all parameters such as request URL, authentication etc., and is NOT a postman request self that is visible under a collection.

AWS Cognito custom auth - sending metadata to a challenge lambda functions

I'm developing a custom passwordless auth to sign into a Cognito user pool. I will describe what I'm trying to implement in case anything is silly. I want a user to enter their email address, then receive a magic login link via email, and when they click on that be taken back to the site and be logged in.
This uses custom auth lambda functions to define/create a challenge with a time based password and send it to the user in an email. I am having a couple of problems:
Problem 1)
When the user returns with the code they might not be in the same browser/device and certainly won't be in the same tab so they don't have the session, meaning I need to call cognitoUser.initiateAuth again. This goes through the define/create challenge lambdas again so a second email gets sent even though at this point the user is coming from the email link so already has the code. Note: the session id is not available in the event object when the challenge is created, also I've read these sessions only last 3 minutes and my time based passwords will last ~15minutes, so I don't think I can include the session id in the email.
Problem 2)
You can login from a few places (browser, android app, etc) and I would like to be able to include the url or at least protocol as a parameter to control what gets sent in the email, e.g. if you entered your email address in the android app then the email you get would be myapp://login?code=xxx and if you did it on the web it would be https://example.com/login?code=xxx
It seems like I would be able to implement both of these to work properly if only I could find some way to send custom metadata through to the DefineChallenge and CreateChallenge lambda such that it would appear in the event object. I thought adding ValidationData to the AuthenticationDetails object would do this, but that information doesn't appear in the event object in the Lambda fns.
The workaround I've found is to create a new client id for every situation - one for initiating auth, one for redeeming token, and repeat for each different protocol. But that is a lot of client ids quickly - a pain to mantain and clumsy.
So tl;dr is: I want to send custom metadata from my cognitoUser.initiateAuth(...) call in JS and have it available in my Define/Create Challenge lambda fns.
You can split the authentication process into multiple custom auth challenges. This allows custom auth state to be supplied via the challenge response as client metadata.
Auth session state must be persisted in a database in order to be shared between devices.
Your custom login flow will probably have two challenge steps: the first prompts for auth type and the second prompts for the secret code. The action taken by the "Create Auth Challenge" Lambda will depend on the auth type. If the auth type is "Email" then the secret code and magic link are generated, stored in DynamoDB and emailed. If the auth type is "MagicLink" then the secret is loaded from DynamoDB. Clicking on a Magic link will initiate a new auth session and automatically supply all the challenge answers.
There are a few other things to consider:
Your magic link needs to encapsulate the Cognito username as well as the one-time secret and probably some other session id that is used as a key in dynamodb.
You probably should not put app-specific links into your emails. Instead associate your domain with your app and/or leverage the redirect URI parameter of your web-based login page.
You can also access custom Cognito user attributes from the Lambda function which can be used to indicate user login preferences (eg Email vs SMS for login codes).

Django-Rest-Framework, update foreign key by ID when using HyperlinkedModelSerializer

This question is derived based on Django-Rest-Framework updating a foreign key BY Id.
I have a somewhat similar problem. I love HyperlinkedModelSerializer. I could navigate through all the links of the API from my web browser (e.g. Chrome, FF, etc.) but when I try to use the API, I have a much work to do in the client app. I have no issue with the GET request. In POST request when updating a model with ForeignKey, I need to construct the URL from the client app (e.g. AngularJS, Android, etc.) before making the POST request to the server. I'm aware of the ModelSerializer which solve the problem from the client app, but it is not navigable from the web browser.
I'm not sure what is a good approach in designing browsable REST API. I'm not sure how most people solve this problem, when they want to create a browsable REST API, at the same time, they don't want to add the complexity on the client app by having to parse the URL-ID before making POST request. Or could this be just my problem that no body encounter.
Why not HyperlinkedModelSerializer does the following instead.
return all the ForeignKey in URL upon GET request. So that developer could navigate the API from their web browser.
accepting ID upon POST request. So that developer could just pass the ID rather than having to construct the full URL from the client app.
Example:
c = Client()
data = {
'user': '1',
'industry': '1'
}
c.post('http://localhost:8000/favorite_industries/', json.dumps(data), 'application/json')
response = c.get('http://localhost:8000/favorite_industries/')
print(response.content)
# [{"id": 1, "user": "http://localhost:8000/users/1/", "industry": "http://localhost:8000/industries/1/"}]
Question:
What could be the advantage from the current design of HyperlinkedModelSerializer?
What could be the drawback from my suggestion?
How can it be done?
I don't see a need to construct URLs at all. When you are sending foreign keys, you are basically referencing another object. This other object you should already know its identifier. In your example, the user id is 1. If you build your API around HyperlinkedModelSerializer, user object will come with its own identifier: url. Before creating your favorite_industries object, you need to know which user to associate with. In normal situations you will have the user object including its url:
{
"url" : "http://localhost:8000/users/1",
"name": "Yeo"
}
All you need to do is sending this identifier as a foreign key:
data = {
'user': 'http://localhost:8000/users/1',
'industry': 'http://localhost:8000/industries/1'
}
I say in normal situations because usually in your client app ids are not entered by users but other info like name are displayed for the user to pick which mandates having the full user object including its url.

jax-rs rest webservice authentication and authorization

I have a web application that needs to allow users using different webclients (browser, native mobile app, etc) to register. After signing in they can access restricted content or their own content (like entries they create, etc).
What I did so far: I created a jax-rs rest webservice (I'm hosting my application on glassfish) that exposes the following methods:
register - user POST's his desired username/password/email/etc; if username/email is unique, an entry for this user is created in the database (I'm using Hibernate for persistence)
login - user POST's username and password. If they are ok a UUID is created and returned to the user (this will be used as a token for future requests). I have a table called logedusers, with userID, token, validSince as columns.
Here is where it gets confusing for me.
Let's say that I have another method, getUserEntries, that should return all the entries made by the user. To make this clearer, there will be a Entry table with the following fields: entryId, userId, text.
What is the best approach here?
What i do now, is I make a get request and pass in the token like this:
localhost:8080/myApp/getUserEntries?token=erf34c34
Afterwards, if the token is valid, I get the userID from the logedusers table and based on that userId, get all the entries and return them as json.
Something like this:
#GET
#Path("getUserEntries")
#Produces(MediaType.APPLICATION_JSON)
public Response getUserEntries(#QueryParam("token") String token) {
String userId=getUserIdFromToken(token);
if (userId == null){
return Response.status(Response.Status.UNAUTHORIZED).build();
} else {
//get some data associated with that userId, put it in the response object and send it back
return Response.ok().entity(response).build();
}
}
However, what happens if I have more methods that provide data if they are called by a valid user?
I'd have to do this check at the beginning of every method.
I want to make this authorization process transparent
So, two major questions here:
Is this design ok? The whole authenticate with user/pass, server creates and stores and sends token to the user, user sends token on future requests.
What do I do if i have many endpoints that need to determine the identity of the calling user? Can I mark them with some annotations, use some sort of security provider / authenticator (where I can add my own logic for validating - eg check to see if the token isn't older than 5 days, etc).
Thanks
Is this design ok? The whole authenticate with user/pass, server creates and stores and sends token to the user, user sends token on future requests.
It's somewhat OK. The conceptual level isn't too bad (provided you're OK with self-registration at all) but the interface needs a lot of tweaking. While yes, POST to register and login is correct, for the rest of your webapp you should be pulling the identity information out of the context if you need it, and using role-based access control at the method level where you can.
Note that your container has a whole set of authentication and authorization-support mechanisms built in. Use them.
What do I do if i have many endpoints that need to determine the identity of the calling user? Can I mark them with some annotations, use some sort of security provider / authenticator (where I can add my own logic for validating - eg check to see if the token isn't older than 5 days, etc).
Do they need the identity? Or do they just need to know that the user is allowed to access them? If the latter, the easiest method is to put a suitable #RolesAllowed annotation on the method, at which point (with suitable configuration; see the JEE5 security docs). If the former, you need to get the HttpServletRequest object for the current action and call its getUserPrincipal() method to get the user's identity (or null if they've not logged in yet). This SO question describes how to go about getting the request object; there are a few possible ways to do it but I recommend injection via a #Resource annotation.
What I wouldn't do is allow users to normally provide their own identity via a #QueryParam; that's just wildly open to abuse. You can allow them to ask about other users that way, but then you need to decide whether you are going to tell them anything or not based on whether the current user is permitted to know anything about the other user. That's the sort of complex security problem that comes up in a real app, and is a good point for needing the current verified user identity.