I am developing a WP plugin that will allow Paypal payments and invoicing. This plugin will allow users to use their own Paypal accounts when accepting payments.
What I understand so far is I need to use REST to enable the Invoicing API. So it leaves me with two options:
Let the users create their own app and enter the client id and secret key into the plugin settings.
Use my own app that I created (only for this purpose) and go with Third Party Payment instead: http://paypal.github.io/PayPal-PHP-SDK/sample/doc/payments/CreateThirdPartyPayment.html
My concern for the first one is that by saving the keys in the database and their site gets compromised somehow - the hackers can execute the API on behalf of their app.
The second one will show the secret keys on the plugin file itself - but then again since the app will only used for this purpose and the Payee/Merchant will only be specified in the plugin settings I guess this is okay? Another advantage would be the user not needing to create their own app.
Which one is better of the two or maybe you can recommend a third option?
Thanks!
Well, you can always generate dynamic payment buttons (similar to what the wizard in paypal does) based on the parameters your user inputs in your plugin and use the express checkout endpoint.But you'll lose some features (like complete customization of the checkout process)
Store the API keys in your database but salt and hash them because they are passwords. Since you are using a third-party CMS, you should assume that sooner or later it is going to have a zero-day exploit and, sooner or later, you will have a hacker with root access to your CMS admin. Design your database and plugins with this fact in mind.
Related
Woocommerce provides an API here which in order to use it, you have to provide a consumer key and consumer secret with a relevant authorization schema. What I fail to grasp is that, shouldn't be there an API for unauthorized / guest users ? I mean, I just want to create a display page (frontend) of available products, but without the need of generating CK/CS. Also looking in a similar question here
it seems that you cannot avoid using the keys. But a second question comes up. The frontend is not supposed to use the keys, because then the e-shop becomes exposed to the client. So, even by generating these keys in order to access woocommerce api, how am I supposed to correctly use them ? Please help me understand the flow.
TLDR;
Do NOT use CK/CS in front end. It's only for use in a secure backend. The keys can be used to read/write anything from products to, orders to all customer related information.
Based on you questions, I suspect APIs might not be the best way to do what you're intending to do. If you do need APIs, chances are, you have two backend servers communicating with each other. APIs are usually meant for use by other applications. For example, a lot of Point of Sale systems utilize this WooCommerce API. You might want to look into extending the WooCommerce plugin itself and creating end points to get the information or perform actions you need.
If you are not familiar with secure Authenticated APIs, I would highly suggest you familiarize yourself with them as failure to secure the website can result in huge financial losses to sensitive personal information leakage of the site users since WooCommerce APIs, at the time of this writing, only allows you to set read or write permissions with full access to everything.
With that in mind I will attempt to answer all of your questions one by one and give an idea of how you should use it.
To Answer your questions
What I fail to grasp is that, shouldn't be there an API for
unauthorized / guest users ? I mean, I just want to create a display
page (frontend) of available products, but without the need of
generating CK/CS
I'm guessing your misconception is that you need to use separate keys for each user. API keys are not meant to give access for front-end users. The API keys generated by the WooCommerece plugin gives full read/write access to any user to view/modify any information including that of other customers. Its meant for admins. If you check the official WooCommerce API reference for retrieving a customer you'll notice that you get to provide an id here. And if you check the response it shows everything from addresses to contact information.
The frontend is not supposed to use the keys, because then the e-shop
becomes exposed to the client. So, even by generating these keys in
order to access woocommerce api, how am I supposed to correctly use
them ?
Its quite simple actually. You just need to get between the communication between the front-end users and the WooCommerce API. If the users needs to be provided information from the WooCommerce end point, you need to get it for them using the CK/CS.
This way, you confirm what information is allowed to view/modify by whom, and the user does not need to be authenticated.
WooCommerce Endpoints <---> Your secure backend service/middleware/controller <---> front-end user
One thing to note though, is that you need to be careful about the parameters a front-end user is able to change in the request to your server end-point that is consuming the WooCommerce API key. A customer should not be able to change the id that is requesting their info for example. Id should be retrieved from the backend from the secure authentication information coming from the front-end.
Currently, I'm working with 2 apps where user can generate a payment token associated with their account. 1 uses the Secure Acceptance Hosted Checkout and the other uses Flex Microform. 1 possible case involves the user's card being captured via the Microform and then later updated via the Hosted Checkout.
The docs mention being able to replace the billing info associated with the Flex token, but it's unclear the mechanism available. I'm aware that the Hosted Checkout supports updating this info, but it's preferred to make the update without prompting the user via the Hosted Checkout so the user never needs to see the default address or require putting in their address twice. Is there an endpoint that can be uses to achieve this?
I don't know if it's the intended way of doing things for cybersource, But there is a soap service named "paySubscriptionUpdateService" in the simple order (soap) api that allowed me update the name & address on a token generated via the flex api.
You can take a look at the simple order API documentation on cybersource website - chapter 7 "Updating a subscription"
https://developer.cybersource.com/library/documentation/dev_guides/Recurring_Billing/SO_API/Recurring_Billing_SO_API.pdf
I'm sure there is a way through rest API too, I'm not sure how to do it yet. I'll circle back if I see something
I have a WordPress website with custom tables that I store data into that was entered by customers. The site owner wants to develop a barcode app that can access this data. When I need the data from these fields to display within the site, I request it from a PHP script running on the server that make calls like get_post_meta().
The owner has hired a mobile app consultant who believes that, if he just has the password to the account where the site is hosted, he can access all of these database fields from the app.
I'm not seeing how this is possible. My understanding is that a mobile app can only access a site by making HTTP requests to it. It has no way of running on the server and executing things like get_post_meta().
Am I missing something?
Thanks
I think you are missing something. Wordpress now has a rest api https://developer.wordpress.org/rest-api/ that can allow a mobile application get at data in your database by making http requests.
The developer will need to be able to enable the Rest Api, but if you give her the password, she will probably be able to do so. Typically this is done using a plugin like: WP Rest API which enables a set of default endpoints which includes post meta data and allows you to add other endpoints
Depending on how the custom tables are set up, they might not be automatically available to the Rest API. However, if you are able to access them using get_post_meta() then I would expect that they would be accessible to the Rest API as well, most likely by adding endpoints.
I'm trying to disable user self-registration in Google Identity Toolkit, or limit the emails that can register comparing them in a database I have. Is it possible? Thanks.
If you want to impose the limitation on the front end, you'd probably have to interact directly with the API (https://developers.google.com/identity/toolkit/web/reference/). If you're using one of the Identity Toolkit libraries, you could also just let people authenticate as normal, but only allow them to complete the registration on your site if the email matches one on the list.
The Conduit API in Phabricator does not support setting of authorPHID parameter while calling maniphest.createtask. I can imagine this is because of security or some logical reason.
But I am developping my own frontend for Maniphest where the users (logged through Phabricator, so they are phab users and have phid) will add and edit tasks. What I need is that if a user creates task, he is also the author of the task.
But the problem is, that I can't connect to Conduit as any other user than "apibot" because I don't have others certificates in my front-end to do it. But if I log in as "apibot", then "apibot" is set as an author of the task.
Three possible solutions came to my mind:
1. retrieve certificate directly from phab's database
2. keep a list of certificates in some file in my front-end and update it manually everytime somebody will register
I guess none of them are really smart...
The third solution would be nice, but I didn't find a way, how to do it:
3. log in as "apibot", get certificate of userXY and then log in as the userXY
What would you suggest?