Please see my reply above. It can be fixed with adding some lines of codes to the payment extension. Isn't it something that can be done to Opencart files itself? This must be a known bug, but I cannot reproduce this on my test site as it's periodic with certain weird factorsstraightlight wrote: ↑Thu Jul 29, 2021 4:11 amEither:FallingUp wrote: ↑Thu Jul 29, 2021 3:00 amAjax Best Checkout - Easy Quick n Boosted on opencart
https://www.opencart.com/index.php?rout ... n_id=20736
It's possbile that this annoying bug can be a problem of Opencart 3.0.2.0 itself or the checkout module.
- Contact the extension developer to resolve this issue
- Install a fresh Opencart store on a test server, not sub-domain, with the checkout module you are using
- Uninstall the checkout module and see if the problem you describe persists
- Create a new service request in the Commercial Support section of the forum to have this issue investigated as a custom job
Without knowing the source of the issue, and without troubleshooting the problem, where the reported issue stands, what you are presuming as an known bug would be inaccurate. Which is why, the four possibilities above were provided unless you could provide error log entries that may prove otherwise.FallingUp wrote: ↑Thu Jul 29, 2021 4:19 amPlease see my reply above. It can be fixed with adding some lines of codes to the payment extension. Isn't it something that can be done to Opencart files itself? This must be a known bug, but I cannot reproduce this on my test site as it's periodic with certain weird factorsstraightlight wrote: ↑Thu Jul 29, 2021 4:11 amEither:FallingUp wrote: ↑Thu Jul 29, 2021 3:00 am
Ajax Best Checkout - Easy Quick n Boosted on opencart
https://www.opencart.com/index.php?rout ... n_id=20736
It's possbile that this annoying bug can be a problem of Opencart 3.0.2.0 itself or the checkout module.
- Contact the extension developer to resolve this issue
- Install a fresh Opencart store on a test server, not sub-domain, with the checkout module you are using
- Uninstall the checkout module and see if the problem you describe persists
- Create a new service request in the Commercial Support section of the forum to have this issue investigated as a custom job
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Having looked at the A and B files. It also looks like it could have an SQL injection vulnerability.
I would possibly look for a different payment module.
1. When the customer simply closes the browser after payment was made (the customer will wait for a confirmation and the webhook of the payment gateway will take care of the rest). This is expected behavior from the customer's perspective for many of the payment gateways we use, we can't blame the customer for not following the "normal" checkout up towards the success page.
2. When the webhook is not processed properly, the customer doesn't get redirected to the success page, but a later webhook mostly confirms the order anyway. This is some glitch in the network, either high load or network issues. We ask our customers to wait for 15 minutes to check if they receive a confirmation email, if they get the confirmation the payment was processed properly. The order_id however is not unset in the session.
So, should the customer make a new order within expiring of the order(gc_maxlifetime), the order is overwritten due to the order_id being the same in the session. I remember the old opencart (1.5.6) didn't remember the order_id and always created a new order_id. Qphoria made a vqmod for this to remember the order_id thus to avoid database pollution. Perhaps Journal 3 and other checkout extensions use the same technique, but forget to unset the order_id in the session whenever an order has been confirmed, but I think it's mostly due to the payment gateways not always redirecting to the success page. I have to do some research for the best possible place in the code to clear the matching order_id in sessions that is linked to a confirmed order.
Edit: In my case it is in fact Journal 3 in combination with the payment gateway which is causing the problem, see post below.
Then, sometime later, re-open the same web browser. Is the cart still there then?
You may also want to check your server's access.log, does it include a call to the checkout/success page, even though you closed your web browser before that? I think you'll still see the access to the checkout/success controller logged in there!
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Webhooks are still relatives to specific payment services. Therefore, what you are addressing about originates from a specific extension where the order ID can be re-compared with the use of an Event prior to unset the created and identical order ID from the success page.LVL91 wrote: ↑Tue Aug 03, 2021 12:45 amI have the same issue with OC 3.0.3.7 and I am not sure if Journal 3 or any other checkout extension is the issue. I think I have pin pointed the issue and it seems to be quite simple. You get the issue when the customer is not redirected to the success page. It seems the only customer-related part in the code that clears the order_id in the session is the logout controller or the success controller. We however have the following cases when the customer is NOT redirected to the success page:
1. When the customer simply closes the browser after payment was made (the customer will wait for a confirmation and the webhook of the payment gateway will take care of the rest). This is expected behavior from the customer's perspective for many of the payment gateways we use, we can't blame the customer for not following the "normal" checkout up towards the success page.
2. When the webhook is not processed properly, the customer doesn't get redirected to the success page, but a later webhook mostly confirms the order anyway. This is some glitch in the network, either high load or network issues. We ask our customers to wait for 15 minutes to check if they receive a confirmation email, if they get the confirmation the payment was processed properly. The order_id however is not unset in the session.
So, should the customer make a new order within expiring of the order(gc_maxlifetime), the order is overwritten due to the order_id being the same in the session. I remember the old opencart (1.5.6) didn't remember the order_id and always created a new order_id. Qphoria made a vqmod for this to remember the order_id thus to avoid database pollution. Perhaps Journal 3 and other checkout extensions use the same technique, but forget to unset the order_id in the session whenever an order has been confirmed, but I think it's mostly due to the payment gateways not always redirecting to the success page. I have to do some research for the best possible place in the code to clear the matching order_id in sessions that is linked to a confirmed order.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
OpenCart still does create a new order ID for each order. So the issue is with the theme/extension/payment module. You may not find a place to clear the order_id in a sessions other than where it already is.LVL91 wrote: ↑Tue Aug 03, 2021 12:45 amI have the same issue with OC 3.0.3.7 and I am not sure if Journal 3 or any other checkout extension is the issue. I think I have pin pointed the issue and it seems to be quite simple. You get the issue when the customer is not redirected to the success page. It seems the only customer-related part in the code that clears the order_id in the session is the logout controller or the success controller. We however have the following cases when the customer is NOT redirected to the success page:
1. When the customer simply closes the browser after payment was made (the customer will wait for a confirmation and the webhook of the payment gateway will take care of the rest). This is expected behavior from the customer's perspective for many of the payment gateways we use, we can't blame the customer for not following the "normal" checkout up towards the success page.
2. When the webhook is not processed properly, the customer doesn't get redirected to the success page, but a later webhook mostly confirms the order anyway. This is some glitch in the network, either high load or network issues. We ask our customers to wait for 15 minutes to check if they receive a confirmation email, if they get the confirmation the payment was processed properly. The order_id however is not unset in the session.
So, should the customer make a new order within expiring of the order(gc_maxlifetime), the order is overwritten due to the order_id being the same in the session. I remember the old opencart (1.5.6) didn't remember the order_id and always created a new order_id. Qphoria made a vqmod for this to remember the order_id thus to avoid database pollution. Perhaps Journal 3 and other checkout extensions use the same technique, but forget to unset the order_id in the session whenever an order has been confirmed, but I think it's mostly due to the payment gateways not always redirecting to the success page. I have to do some research for the best possible place in the code to clear the matching order_id in sessions that is linked to a confirmed order.
This is because if a payment doesn't require the customer to return to store and uses a callback instead (such as PayPal Standard). There is no way to access the customer's session from the callback.
If the theme/extension/payment module wants to add orders in a different way, then it need to add something to prevent duplicates from happening. Only overwriting orders with a status of 0 would be a start.
If you do need a workaround, maybe clearing the order_id in the session on entering checkout. But if the checkout has been modified this may not help.
This bug could also exist with other checkout extensions. I guess poorly written checkout extensions with semi-poorly written payment gateways can cause severe bugs. To be continued...
Update 1: Simple fix done for my website which should fix 99,9% of the issues. After further consideration I think it could still be exploited and I have to come up with a better fix to solve this for all situations. Since I am now on vacation I will look into this further after my vacation.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
I had some issues with orders being overwritten, yet already confirmed, processed and shipped. As it turns out, the Quick checkout from Journal 3 has a major flaw. It uses the order_id in the session (if available) to update and confirm the order on the checkout page, but due to payment gateways, our customers will not always return to the success page. Webhooks usually take care of order confirmation, so quite some customers will simply do the payment, close the browser and never reach the success page. Due to this use case, the order_id never gets cleared in the session (by loading the success page) and the next time the checkout is used to edit anything in an order, it uses the exact same order_id to overwrite the entire order with the contents of the cart and other order data. There are no checks done for the order_id in the session being valid. This is extremely dangerous as customers will have a way of editing orders, even after they have been confirmed and paid. As a result stock levels don't match anymore and loss of money could be involved.
This issue doesn't exist (to some extend) as long as the customer will always follow the complete steps from checkout-->payment gateway-->success page as this will clear the order_id in the session. This is why you probably haven't heard from it much, also due to sessions expiring over time which also clears the session data.
There is another very dangerous situation possible for customers that do load the success page in the end:
1. Customer confirmes order of e.g. €1.00 and gets redirected to the payment gateway.
2. Customer uses another tab in the browser to edit the order using the checkout with more products, e.g. €200.00
3. Customer completes the payment for the €1.00 amount, but the €200.00 order will be confirmed.
4. Payment gateway doesn't check the order amount paid compared to the order and order is confirmed. Remaining payment of €199.00 will probably only appear when doing tax administration and if Opencart orders are compared to actual paid amounts.
This is the most dangerous situation possible for which the customer can leave little trace of what happened:
1. Customer confirmes order of e.g. €1.00 and gets redirected to the payment gateway.
2. Customer completes the payment for the €1.00 amount and relies on the webhook of the payment gateway to complete the order.
3. Order is confirmed and all seems well. The order however is not instantly processed of course, only when the packing slip is actually printed. We presume it takes e.g. one hour for the processing to start.
4. As the order_id is never cleared in the session (no loading of success page), the customer can now use the checkout to overwrite the order with whatever they want, e.g. €200.00 of products.
5. The order is eventually processed and shipped using the new overwritten order data.
6. After you receive the shipped update, you can go back to the checkout and overwrite your order again, but then with the first €1.00 product. You will have paid €1.00, getting €200.00 of products, yet the system will contain data you only got a product worth of €1.00.
Since OC default will always create a new order_id for each confirmed order getting redirected to the payment gateway, this issue doesn't exist with any of the payment gateways using the OC default checkout.
I have verified all the above exploits. So far, they have not been exploited at our e-store, but we did have overwritten orders that were already confirmed, some times resulting in differences in order amount and type of product.
Please take note that the modification has only been tested on my own OC 3.0.3.7 + Journal 3.1.8 system with my payment gateways. While the modification is quite simple and universal, I advise to fully test each payment method to confirm this works for you. The OCMOD file contains some comments to explain what is done and why.
I hope this helps other users to get rid of this nasty problem in the Journal 3 Quick checkout. If you have another checkout solution with similar issues, you might be able to use (part of) the code to solve the issue.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
If these one-step checkout solutions use the order_id in the session as reference and create orders with order_status_id = 0 to save all the checkout data, then yes, they could very well have the same issues. The "Quick N Boosted" one-step checkout extension could be one of those as said in another post here.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Thank you for the feedback straightlight, but that is not exactly what my OCMOD is doing. It mainly does these things only:straightlight wrote: ↑Wed Aug 18, 2021 11:03 pmChecking the last order ID created does not confirm that this last order ID belongs to the current guest / customer with this XML file.
- Save the order_id that has been confirmed (and used by a payment method). It uses the session to save it.
- Check/compare the last confirmed order_id in the session (not THE last order_id, just the last confirmed order_id saved in the customers session)
- Check if the order_id being used exists in the database with order_status_id != '0' (not required actually, just extra safety)
This prevents all the nasty things for me. Also, I got confirmation from the Journal 3 developers that they will look into it and check if they can implement it for the next release.
Hello good morning. I have the same problem, only with Opencart 3.0.3.2, would your solution work?LVL91 wrote: ↑Fri Aug 13, 2021 1:19 amThis will probably be the last update for some time. The reply from the Journal 3 developers was not quite what I was expecting. Therefore I will explain what issues I had, explain the root cause with possible exploits involved and attach a OCMOD with fixes for these issues.
I had some issues with orders being overwritten, yet already confirmed, processed and shipped. As it turns out, the Quick checkout from Journal 3 has a major flaw. It uses the order_id in the session (if available) to update and confirm the order on the checkout page, but due to payment gateways, our customers will not always return to the success page. Webhooks usually take care of order confirmation, so quite some customers will simply do the payment, close the browser and never reach the success page. Due to this use case, the order_id never gets cleared in the session (by loading the success page) and the next time the checkout is used to edit anything in an order, it uses the exact same order_id to overwrite the entire order with the contents of the cart and other order data. There are no checks done for the order_id in the session being valid. This is extremely dangerous as customers will have a way of editing orders, even after they have been confirmed and paid. As a result stock levels don't match anymore and loss of money could be involved.
This issue doesn't exist (to some extend) as long as the customer will always follow the complete steps from checkout-->payment gateway-->success page as this will clear the order_id in the session. This is why you probably haven't heard from it much, also due to sessions expiring over time which also clears the session data.
There is another very dangerous situation possible for customers that do load the success page in the end:
1. Customer confirmes order of e.g. €1.00 and gets redirected to the payment gateway.
2. Customer uses another tab in the browser to edit the order using the checkout with more products, e.g. €200.00
3. Customer completes the payment for the €1.00 amount, but the €200.00 order will be confirmed.
4. Payment gateway doesn't check the order amount paid compared to the order and order is confirmed. Remaining payment of €199.00 will probably only appear when doing tax administration and if Opencart orders are compared to actual paid amounts.
This is the most dangerous situation possible for which the customer can leave little trace of what happened:
1. Customer confirmes order of e.g. €1.00 and gets redirected to the payment gateway.
2. Customer completes the payment for the €1.00 amount and relies on the webhook of the payment gateway to complete the order.
3. Order is confirmed and all seems well. The order however is not instantly processed of course, only when the packing slip is actually printed. We presume it takes e.g. one hour for the processing to start.
4. As the order_id is never cleared in the session (no loading of success page), the customer can now use the checkout to overwrite the order with whatever they want, e.g. €200.00 of products.
5. The order is eventually processed and shipped using the new overwritten order data.
6. After you receive the shipped update, you can go back to the checkout and overwrite your order again, but then with the first €1.00 product. You will have paid €1.00, getting €200.00 of products, yet the system will contain data you only got a product worth of €1.00.
Since OC default will always create a new order_id for each confirmed order getting redirected to the payment gateway, this issue doesn't exist with any of the payment gateways using the OC default checkout.
I have verified all the above exploits. So far, they have not been exploited at our e-store, but we did have overwritten orders that were already confirmed, some times resulting in differences in order amount and type of product.
Please take note that the modification has only been tested on my own OC 3.0.3.7 + Journal 3.1.8 system with my payment gateways. While the modification is quite simple and universal, I advise to fully test each payment method to confirm this works for you. The OCMOD file contains some comments to explain what is done and why.
I hope this helps other users to get rid of this nasty problem in the Journal 3 Quick checkout. If you have another checkout solution with similar issues, you might be able to use (part of) the code to solve the issue.
Can you tell me how to install it? I Copy your file directly to the System folder via FTP and refresh modifications, but in the modification console it does not appear.
Thanks!
open catalog/model/journal3/order.php.
change line 168-173 to below code:
Code: Select all
/*if ($order_id) {
$this->editOrder($order_id, $order_data);
} else {
$this->session->data['order_id'] = $this->addOrder($order_data);
}*/
$this->load->model('checkout/order');
$order_info = $this->model_checkout_order->getOrder($order_id);
if ($order_info) {
// If order status is 0 then becomes greater than 0 send main html email
if ($order_info['order_status_id'] > 0) {
$this->session->data['order_id'] = $this->addOrder($order_data);
}
// If order status is not 0 then send update text email
if ($order_info['order_status_id'] == 0) {
$this->editOrder($order_id, $order_data);
}
}
______________________
https://www.opencart.com/index.php?rout ... n_id=42966
Users browsing this forum: No registered users and 78 guests