Client-only integration, risks and limitations in using Vue Stripe - 6
Let's enable customer integration and talk about limitations and risks.
We are here in which when we click on it, I am going to zoom in a little on the button, the following message will appear that you have to enable integration with the client on your dashboard:
v3:1 Uncaught (in promise) IntegrationError: The Checkout client-only integration is not enabled. Enable it in the Dashboard at https://dashboard.stripe.com/account/checkout/settings.
at Sl (v3:1:461068)
at e._handleMessage (v3:1:469393)
at e._handleMessage (v3:1:85275)And here, in case you are already a good connoisseur of this type of technology, you can already see a little bit of the limitations that we have with this plugin, at least for the initial configuration. I'm going to continue talking about that here, click on the following link:
https://dashboard.stripe.com/account/checkout/settings
Or simply follow the following route, which would be your account settings, here I already have it loaded, we waited 10,000 years and went down here, feel free to read the settings, I'm not really going to explain it to you, they are settings for the strike service, if you have any questions about them, simply contact the strike team here, the help section, again, we are interested in the integration, and down here at the end of everything, at least in my case. Remember that these interfaces can change little by little, you will see somewhere in life, enable integration only for the client, which is precisely the option that we have here and it is the one that is indicating to us that we have to use it here, notice something important, which is the meaning of this, obviously we have to click on it. Click here and here it tells you some information. Basically what it is telling you is that all requests will be made with your public ID, which may not be so secure.
In integration only the client is more insecure since only the public key is used
Since in this type of services there always has to be a private key or the secret key, practically all of them work like this, the secret key is usually used on the server side to precisely guarantee that the operation is working correctly, it is the same thing that we did with PayPal in which on the client we had the plugin to use it here on the client side, we put it together with the public key, but on the server, once the order was created, PayPal took care of it or through the secret key and the order already created, we approved that order, so we have an additional layer of security since obviously the secret key and the public key work in a similar way to what a password is, a user and a password in which the user is the public key and the password is the private key, something similar in this case you are only working with one that is the public key, which is why it is much more insecure, even so, it is like I say a little silly because the hacking that they could do to you is that somehow they intercept the request here and change your public key for the public key of that attacker, then well if he was hacking him, assuming that that change was only can persist in succession Ppro can be a bit risky
For example if you had that public key in the database then somehow he intercedes and injects his own so to speak eh all the payments would fall into his account but that is why the importance of the secret key anyway we are going to solve that in the following videos but I suppose it is a bit what they are telling you here then
We are going to give it here to allow and that is why it is obfuscated by default because basically it is a more insecure operation than doing it as mentioned and at this point it should work so we are going to reload here again here we have the button we give it a click let's wait and this is what should happen is to allow the Stripe payment window and place some of the test cards
https://docs.stripe.com/testing
The main problem
If we are selling something, be it a book, a course, or tickets online, I don't know what we are selling there and it is assumed that when the user makes the payment, we assign that record to them, something that we can easily do with PayPal according to what we saw previously, but here it is not possible, that simple, with the configuration that we currently have, it is not possible to do that type of operation, therefore it does not go beyond simply a quick access so that they pay us to an account configured using the public key, so nothing, I simply wanted to tell you that
In summary, it is a little more insecure, you could say, because it is only matching with a key, which, depending on how you do the integration, could be more susceptible to hacking, and well, with that, the money that the page is remembering is passed on to another account, and on the other hand, it is not possible, at least with the configuration that we currently have, to be able to assign products, that is, to do certain logic to our application so that once the payment is made, it can release the products that the user has purchased based on the purchase that they have just made, that is, we are going to solve it in the following voices, but I simply wanted to give you the limitations, so let's go there.
- Andrés Cruz
Develop with Laravel, Django, Flask, CodeIgniter, HTML5, CSS3, MySQL, JavaScript, Vue, Android, iOS, Flutter