[natewallis]

Hi there, 

 

We are having a random issue on our site which is baffling me. 

 

On occasions when we go to print an invoice, it will generate an invoice, but for a completely different store on the internet.  Its not like someone is trying to modify our own invoice with their payment details, it is a completely different invoice using a completely different layout than what we are using with a completely different currency.   With customer details and products that we don't have on our system.  Its very odd.  The two sites are:

 

- Enagic.com who also use CS-CART and appear to be a reputable company

- Discount Junction (I can't find a website for these guys, so I have no idea how the invoice is being generated)

 

I have checked the server logs and there has been no unauthorised access to the system via SSH or any modifications to the source files of the site.   I have the source for the site in version control and can pull down a fresh copy. 

 

This doesn't happen with invoices that are emailled to the customer, it appears to have happened only when we select "Print Invoice (PDF)" from the backend.  So its good that our customers are not being effected.  If this is a hack, I don't understand the purpose of it as the customers are not receiving this content. 

 

The situation is not easily repeatable and only being experienced by one person on the team which made me think that a virus on their computer might be the cause?

 

I am struggling to think of the cause, but one theory was a DNS issue which caused our domain to point to someone elses?  Although it seems a bit of a coincidence that we keep getting other CS-CART sites. 

 

We are running CS-CART 4.2.4

 

Any ideas?  Your thoughts would be greatly appreciated.

 

 

[P-Pharma]

What addons and styles do you have installed?

[eComLabs]

We have similar issue and we are in contact with CS-Cart team regarding the problem now. Please also contact CS-Cart support team

[gvs]

Hello!

 

We're so sorry about the inconvenience caused by this issue. We've resolved it, and you shouldn't receive other stores' PDF invoices anymore.

 

Back in September, we've been doing some optimizations regarding heavy PDF generating. In the process, we made a mistake that resulted in this bug: the same PDF invoice would occasionally be sent to two stores.

 

Please accept our sincere apologies for the trouble.

[natewallis]

Ok, thanks for updating this.  

 

I am curious how that is even possible. isn't the PDF generated on my server?  I don't see how its possible for my server to generate a PDF with details of a customer on an unrelated server... 

 

Cheers.. 

[tbirnseth]

PDF's are generated at Simbrisk cart-services.com website.  That's a pretty serious breach of security/confidentiality since customer info is present in those invoices....  Not good.

[Flow]

PDF's are generated at Simbrisk cart-services.com website.  That's a pretty serious breach of security/confidentiality since customer info is present in those invoices....  Not good.

 

Seriously? I am pretty sure this is even illegal in some parts of the world. Cs-cart please change this?!

[natewallis]

Yes I am suprised by this too.   I hadn't looked at the code and just assumed that PDF generation would be done in the code since there are so many good libraries out there in a wide range of languages (PHP included) that would take care of it for you.  

[tbirnseth]

app/Tygh/Pdf.php

private static $_url = 'http://converter.cart-services.com';

[mokeshop]

how will this issue will be resolved'''

[tbirnseth]

If you read #4, it was fixed.  The issue was optimization they tried to do returned erroneous results.

[natewallis]

I think maybe they meant - "when it will be changed so that PDF generation takes place on our own server"?  Well if they didn't  - I'll ask the question

[tbirnseth]

It used to be that way and was fraught with maintenance issues.  It was moved to the off-board solution (software as a service) at about the initial V4 release.  Up till now, there has been no issues and we don't have an error_log file filled with notices/warnings from the old PDF library.

 

I doubt this will be brought back into the core.  Why have to maintain/manage 35K instances of something when you can maintain/manage one?

 

It would be akin to asking that Google do all their analytics on your server....

[natewallis]

Ok,  I didn't see an error_log full of PDF issues in V3.  I don't understand the headache here and there were no problems, but there are now and definitely one of major concern.    If I have received invoices from random companies then its quite likely that other companies have received my invoices.  I am sure the Indian customers invoice I received would not be happy I received their information, nor would my customers be happy about the potentially reverse situation. 

 

CS-CART don't need to manage 35K instances.  People are responsible for their own installations and CS-CART get paid for support if people need it.  If thats the line you want to draw, then lets just all move to the cloud.  One of the main attractions of CS-CART to me is being able to customise it easily and have it run on my server.  What happens if "converter.cscart-services.com" is unreachable?

 

I guess the issue might have been when people start customising their invoices with content that isn't compatible with the renderer?  Anyway, as the forums are littered with people having issues once they start customising their systems, I don't see why we should be worried about offloading PDF generation.

 

I am glad its been fixed.  But I would at least like the option to decide if customer information is sent elsewhere for something as simple as generating the PDF.   At least give us a hook. 

[mokeshop]

yes... how fast and secure is converter.cscart-services.com and can it manage 35k and raising connections?

[tbirnseth]

First off, I'm not defending any choices (either side - there are pluses and minuses to each).

 

You can add your own hook and request that it be added to the distribution.  Or you can intercept the request using a 'pre' controller for orders and then call your own renderer if you want.  You can do that today without any modification to the distributed code.

 

Note that PDF generation of an invoice (or any other document) is NOT the default and hence I'd expect the volume to actually be quite low relative to the number of orders placed.

 

Given that cs-cart is not chiming in after communicatiing the problem was solved, my guess is this is all moot and that no other change would be forthcoming.  That they saw the original problem and buzzers went off internally leading to a fix, is a plus.

[Flow]

The main problem here is privacy laws. In the EU you can't just send over customer details to 3rd parties without warning customers up front in general terms, and this needs to be very detailed. We do the same for google analytics, facebook like buttons, pinterest buttons, and so on, and it needs to be according to law. Therefore I like keeping this list as simple as possible. You can download compliant texts for the big guys, but not this we'd need to hire a lawyer to write a compliant text, and we'd need details from simtech.

 

Also some customers will not like having their details being sent to yet another company. Therefore, it is a problem.

[tbirnseth]

Or you can disable generation of PDF files or install a hook to do so locally if you choose.

 

There are lots of 3rd party scripts that are called without any knowledge about what they do, what they transmit, etc.  Look at every "seal" that is generated or tracking script or shopping integration and tracking.  Are there disclosures for each payment provider where order-info is sent?  What about things like mailchimp?  The 'disclosure' part of a site would be overwhelming to a consumer.

 

I understand the concern.  In today's world it is becoming increasingly difficult to differentiate between local service and web services.  If you used Merchium for your storefront, do you have to disclose that your site is hosted in Russia and all data is accessible by root administrators that are not related to your company (applies to any hosted environment including local sites unless you host in your own data-centers)?  What about disclosing where your SMTP server is located since personal data is transmitted there to be conveyed via email to the customer...

 

I think the issue is more about storage of information versus utilization of information.  I can't address directly since we don't have those laws here in the states (though some states have tried to impose them and found it uncontrollable). 

 

I would think Simbrisk would chime in to convey whether they store the info or not; or whether it's simply held in memory for generating the pdf and whether that resulting pdf is also stored or not.

 

Love these philosophical discussions.  This one two will die out after a week or so of inactivity....

[mokeshop]

 

Hello!

 

We're so sorry about the inconvenience caused by this issue. We've resolved it, and you shouldn't receive other stores' PDF invoices anymore.

 

Back in September, we've been doing some optimizations regarding heavy PDF generating. In the process, we made a mistake that resulted in this bug: the same PDF invoice would occasionally be sent to two stores.

 

Please accept our sincere apologies for the trouble.

 

 

 

hello,

 

which version of cs cart is fixed from this bug-

[The Tool]

Since the PDF is created on their end...all.?