I am currently using the PayPal API to process payments inside my application. My problem is the following: My application is now capable of creating an order and letting the user approve the order. What I want to accomplish is authorizing the amount the user approved to directly after the user approved the order. I know it is possible to authorize an order but from what I understand this is only possible after the user approved the Order. So what I want to know is the following: is it possible to let the user approve with the order and then authorize in one step, without the interfering of my backend(Spring Boot). Or should I let the frontend make a call after the user approved, so that another endpoint in my application can try the authorization of the funds. It al comes down to the fact that I don't know when to make the authorization call. What is the best practice?
So basically you want to create an order with "intent": "authorize" and then authorize it from your backend after approval (rather than capturing it, as would be the case for intent:capture).
For this you need to make two routes, one for 'create an order for authorization' and one for 'authorize an order', documented here. These routes should return only JSON data (no HTML or text). The second one should (on success) store the resulting authorization ID, purchase_units[0].payments.authorizations[0].id ...for later capture
Pair these two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
Related
For my web app I am trying to allow the user to add multiple payment methods. I am using the user token in order to gain access to the income feature. However, there appears to be no way to allow multiple payment methods because the user token only corresponds to the data most recently entered through Plaid Link and trying to create a second user token fails because you cannot have repeat client user ids. How exactly do you get around this?
I an developing a chrome extension which doesn't has any sign up or sign in flow, instead depends on authentication of a separate web app. I started integrating mixpanel and tracking user events anonymously, Now i want to identify those anonymous users using "alias" and "identify" api. I have a user_id for identifying users from the web app exposed REST api. Now if i apply a boolean check and make sure i call mixpanel "alias(user_id)" once and call "identify(user_id)" every time user visits a page, I can see a user entry in explore tab of mixpanel but live events tab has a anonymous user with same user_id and its tracked data, I wish to link such anonymous users with appropriate user profiles.
Please help me with this if you have some understanding of mixpanel. I am new at this.
Since I didn't had a sign in or sign up flow, I cannot use
mixpanel.alias
Hence i am now calling
mixpanel.identify
As soon as user installs the plugin, Since "identify" api can be called any number of times for an user, We are able to track all future events as soon as plugin gets installed.
This way by not letting the user generate anonymous events we can handle such situation.
I'm designing an app that counts on accessing multiple API's that need the certain users credentials which are provided when a user allows access via OAuth. I'm new to designing programs like this and I'm trying to wrap my head around the easiest way to do this. Here is what I was thinking:
During the Oauth process I specify the callback url (lets call it A)
Create a POST route for url A that points to a function in the user controller
That function then parses the JSON data with the API Key+Secret, hashes the data, and stores it in a column of the user table.
Would this be the best way to go about this?
One thing I'll say is don't tie these directly to your users. Sometimes users may want to authorize multiple accounts, and sometimes multiple users may authorize the same account. Since you can only have one active refresh token per oauth account, these creds should be kept in a separate table and then linked with a many-to-many for flexibility
I'm currently working on a iphone/android project where the mobile talk ta java backend server through REST API calls.
The Java backend is done using Spring and its Authentication system (with a JSESSION ID token)
I'm not an expert in security but I can see that if not implemented correctly there could be quite a lot of issues.
One of my biggest concern would be user creation for example.
When the app creates a user it simply makes a POST request to (url.com/rest/create)
How can I avoid, server side, that a malicious user puts this url in a loop and create thousands of users ?
What are common best practices to secure API calls ?
Is the Spring Authentication token enough ?
Thank you!
It's not really possible to prevent a client from making many calls to your server. A malicious user can create a script or application firing requests to your server.
The solution is to authenticate and authorize the calls to the server. You give certain users (for example administrators) the privilege to create users. You trust those users to behave in a correct manner. You have your users authenticate before they call the APIs on your server. Then, on the server side your check who the user is and what he/she is allowed to do.
If you are still concerned about privileged users not behaving, you can assign quota to each user on the actions they are allowed to perform.
The hightech solution (with as much framework fuctions as possible) would be
first: have a created-by and created-date field at the entity you want to protect (I recommend to use Spring-Data-JPA Auditing for that).
second: create a custom spring method (or web) expression method that is able to check how many items the current user has created in the (for example) last 10minutes and if this are more then (for examle) 20, then return false (or make them parameters of the method).
Then you can protect your method (or url) with that expression (#PreAuthorize("createsNotExeced(10, 20)"))
But this is the high tech solution - it would be quite intresstion implementing them when one wants to learn spring security. (and you would need to add some caching, but this is also a Spring feature).
The lowtech solution would be: put an list of timestamp in the users session, and add an new item to that array whenever the user creates an new item. When the last (for example) 20 timestamp enties are within the last (for example) 10 minutes, then throw an TooMuchHeavyUseRuntimeException or somthing else.
I'm currently implementing this library ember-simple-auth to manage authentication in the emberjs application (shopping cart) that I am currently building.
The difficulty that I encounter is that the library manages authentication rules after logging in very well but not before logging in.
So here is the scenario:
The application must talk to the backend server to retrieve a session token for every user. This is necessary so that the user can save their items temporarily in the server side using session data. Something that you would expect for a shopping cart.
Then when the user is ready to move forward the application will then display the login screen and the user can authenticate themselves to checkout their items.
However, I can't seems to figure out yet how to do this using simple-auth. If I create a custom authenticator that just fetches token id from the server, it will mark the session as authenticated and will not ask for login on the authenticatedRoute.
In general what I'm trying to do are:
Customer visit the website
The application fetches session token from the server
Customer clicks around and saves item into the shopping cart. The data is synced with the server using the session token
Customer ready to checkout and navigates to checkout page
The application intercepts the route and redirect the customer to login route, where the customer can login and resume checkout.
I hope the above information is clear enough. Any hints and help will be much appreciated. Thanks.
I would probably only use Ember Simple Auth from the point on where the user actually logs in. Before that instead of using a session token to identify the basket, I'd probably explicitly create a basket on the server side (POST /basket) and then add to that via a REST interface (PUT /baskets/:id/items or so). That way you're not sharing state between the client and the server and have a clear interface. You also don't need to "abuse" Ember Simple Auth which probably only leads to other problems later on. When the user logs in then, you simply assign the previously created basket to that user and go on.