|
|
- es - |
|
|
Hello Kevin I'm unable to reproduce the behaviour on my local machine, can you please check the "source/tmp" folder if there a file exists, named "paypaltoken_<shopId>.txt" (f.e. "paypaltoken_1.txt")? In v2.2.3 an issue has been fixed, which had the described symptoms. It was caused by requesting the paypal token too often in short succession, and fixed with a simple file cache. So, if the paypaltoken file exists on your system, we might have another variation of the problem, which we need to investigate. Otherwise I would suggest trying to install the module anew and give it another try. Sincerely Lars |
|
|
Hello Lars, there is no such file in the tmp folder. It's probably worth noting that our tmp is not located in source/tmp, we've set a different folder via the sCompileDir property in the config file, even tho I don't think that should affect the functionality, files like "oxeec_langcache_*" and all other relevant cache files are in the folder. A reinstallation of the module hasn't changed anything, it still does not generate that file and does not work. |
|
|
Hello Kevin Thank you very much. It is indeed no problem to move these folders, as long as permissions etc. are fine, which they are apparently. So no worries here. I've redone my local setup and repeated the steps multiple times, still not able to reproduce it. However, just to be absolutely sure, I wanted to check another file. modules/osc/paypal/src/Core/Config.php line 277-282 should be: public function getTokenCacheFileName(): string { $config = Registry::getConfig(); $shopId = $config->getActiveShop()->getId(); return $config->getConfigParam('sCompileDir') . 'paypaltoken_' . $shopId . '.txt'; } If this is missing, the module isn't the right version. The code is triggered only after the last step in the paypal popup, a button labeled like "Return to John Doe's Test Store" (I made screenshots). Only if this button appears and is clicked, the callback to the shop is made, during which the token file is generated (I incorrectly assumed that it would be created before the popup..) Is the shop reachable from the internet, or is on a local environment (with a local URL)? Do you connect a sandbox or a live system (and have you tried vice versa)? Sincerely Lars Paypal-connect-shop.png (21,073 bytes) Paypal-after-connect-shop.png (26,635 bytes) |
|
|
Hi Lars, the code snippet you posted above is indeed contained in the Config.php file - I checked directly on the server via nano. So I seem to have the correct version. The shop is reachable from the internet, there also is no .htaccess file or similar protections in place - that was my first hunch, so I disabled all of them, but it didn't do anything. Right now, we're only working with the sandbox mode. We don't have the paypal access data from our customer and we would prefer not to have them. The plan is that the customer is going to go through that process himself, especially because, sometimes, paypal asks for additional information that I might not be able to provide if I go through that process instead of the customer. tokencachefilename.png (50,240 bytes) |
|
|
Hello Kevin Thanks again. Unfortunately it seems, that the fix doesn't address the issue you're experiencing. It's the proper module version, a real URL, and the Paypal sandbox, just what I'm using Last thing I can currently think of, is to verify Client-ID and -Secret using Postman, see https://developer.paypal.com/api/rest/authentication/#link-postman (these should be in the var/shops/1.yaml) I will inform the team and we'll probably have a discussion with somebody from Paypal about this problem. I'm sorry that I couldn't help you to fix right away.. I'll post back here with news as I have them. Sincerely Lars |
|
|
Hi Lars, sorry for my late reply, I was busy last week and sick this week. However, I checked the client-id and secret via postman as described in the article you linked and it seems to be fine. I get a json with scope, access_token, nonce etc, just as described in the article. So this seems to be working from what I can see. |
|
|
Hello Kevin Thanks for the confirmation. We're still unable to reproduce the issue, having tried it on different machines and environments, and we have no other complaints from customers about this issue. We've discussed internally, our last suggestion would be to set up a fresh installation on a local machine, with only the PayPal Module installed and check, if it still happens. Preferrably use a laptop for the installation, as you then have the opportunity to try it from a different location/network.. best-guess now is, that it has something to do with the network setup, in which the problematic installation runs. Sincerely Lars |
|
|
Hi Lars, my apologies, but I was unclear on my initial post. The problems we have are on the update system at our hoster, on the exact same server the current production environment is running, so those are not locally somewhere. Locally on my dev environment, it does work. However, that doesn't help us as the customer has to be able to go through the onboarding himself. We're talking about 30+ subshops, and I can't do that for all of them locally on my dev environment and then upload the created credentials, that is just not feasible, ignoring the fact that we'd need their paypal credentials, which isn't that great either. If it is related to the network, I don't have a clue where to start looking for the error as the "rate limit" error is rather generic and also doesn't imply that there is something wrong with the network itself. I'm more than willing discussing this with the hoster but I have no clue what to ask for. |
- Anonymous
