Hello everyone. I just need some ideas on a direction to go. I have financial software that runs payroll. It is built on Xojo cloud using Xojo. Certain things from the program can be printed. Currently Im creating a pdf and then the user can print the pdf. The problem with this method is that user can print things such as a check an unlimited number of times. That’s a security problem.
I need to figure out a way to limit the printing of something to just one time unless the program can record that is being printed (or generated as a pdf) again. On desktop we are already able to limit the printing to one time by directly accessing the printer. However, on web we are not able to do this (that I know of).
Does anyone have any ideas how I can limit printing to one print? Any ideas or helpful. If I need to scrap pdf and print from html or something else then that’s fine. Thanks everyone in advance.
I assume the user is using pre-numbered check blanks they order from their bank?
I think I’m going to challenge the idea that the user printing multiple times is a security risk. QuickBooks allows this, for example - and specifically asks you if the check printed correctly (perhaps it jammed, for example). Is there a deeper reason you’re looking to impose this restriction?
The user is using prenumbered checks. There is no deeper reason for restricting printing again. After discussing with my boss for a while we came to the conclusion that printing the check a second time is a security problem. I understand being able to print checks again if the printer jammed. It sounds like Quickbooks is asking for a reason. If the check did jam then they are doing something like moving to the next check number or something on the back end. They are making a record of the check or doing something with positive pay to reconcile with the bank and invalidate the first check.
Our security problem is that if a second check is printed, whether by mistake or for other nefarious reasons, we do not want two checks floating around out there. They are both valid checks and a bank will cash them both with no liability to the bank because they are valid. That’s a huge security issue and opens us up to liability.
In the case of the pdf, we do ask if the check printed correctly. If the user says it does not then it is recorded in audit trail, the first check is cancelled and a new check with the new check number is generated for the user to print. If the customer is on positive pay, the first check no longer is on the list of valid checks for the bank to cash.
The problem you’re going to run into is that any printable format that comes from the web is going to be intermediary, and relies on an insecure platform (the user’s OS) to do the actual printing.
The only way to ensure a single print is if your software interfaces to the printer directly. That means you need a desktop app to work as a print server that your web software communicates with.
If it was mission critical for me, the way I’d probably approach this is to build a print server app and deploy it to a Raspberry Pi, which I would provide to the user at low or no cost to connect their printer to.
If you don’t control the print mechanism directly, there’s really no way to stop someone from printing a second time. Even then, certain printers may have firmware that allows them to repeat a previous print. Not a lot you can do about that except keep a list of such printers and blacklist them from your print server app.
Honestly - this might be a situation where you simply need to disclaim liability via the licensing agreement or contract. It just isn’t possible to prevent this from happening via software (at least, not with the constraints you have).
I’m fairly certain I could trick almost any laser printer into repeating a print, even if it didn’t have that feature built in. Their minds are very simple and vulnerable to deception.
And how do you stop them from typing “2” into the copies field in the print dialog?
Something to consider (having used quickbooks for my own business years ago) was it was really handy to have the reprint feature for multi use printers where most of the time you had plain paper and then you manually fed checks, because sometimes they just didn’t feed… you you forgot to put the check in at all… or it was upside down… or any number of other issues.
I think you’re trying to solve an issue that isn’t an issue honestly. The only person that should have the ability to print checks is a person that the company trusts not to steal from them… because honestly the person doesn’t need your software to write those checks manually.
Our software has been an evolving program since 1980. Over the years my boss has seen a lot of stuff. In theory it’s great to say the person printing the check should be honest. I agree with that. Sometimes a person may be honest but see that opening to take advantage of a flaw. When our users are handling multimillion dollar budgets in the schools here, lots of things happen. We as a company have a huge liability protecting the money. Why leave that opening for something to happen when we already solved this years ago with the desktop version?
If I go back to my boss and say “there’s no way to restrict printing a check to once unless the software knows its printing it again” then he’s going to not want to use Xojo web because it feels like it is taking a step backwards and we are losing technology.
I understand the arguments. I understand limiting our liability with a waiver. But can it be done? Does anyone know of a way that it can be done? Can it be done with javascript running in Xojo? Can it be done with an add on like MBS or something? Is it even possible on the web? Do browsers have printer access?
You will never find a way to truly restrict this. Whatever current implementation that you think is restricting check forgery is just making it more difficult, not entirely preventing it. I’m assuming the software you’re replacing isn’t a web app, where you’re able to interface with the print driver more directly, and that’s giving this false sense of additional security and appearing to show a shortcoming in Xojo Web.
There’s no web application framework that I can think of which will be able to accomplish what you want because browsers protect the users not the application. The user controls the print dialog where they can specify a number of copies, the user controls the OS spooler and cache, and there are myriad other ways to forge checks or likewise repeat a previous print operation. This is not an issue with Xojo.
If the users have access to checks (or account and routing numbers), you’ve already lost the battle, the technology doesn’t matter. Your software users will have to be mindful of matching check numbers and amounts and detecting forgeries by balancing accounts, and I’d hope they already do match payments to invoices.
I would say then they have the wrong person doing the job if they take advantage of the flaw. If companies are truly worried about such things then the printer where the checks are should be in a different room where another person needs to pick them up and verify their validity before they are issued.
When my company worked on contract writing systems in Florida 20 years ago for a board of education, they had their own procedures in place to protect themselves from this kind of fraud. Every check had to have a contract and issuance number on it (They used ContractNumber-issuanceNumber) which was matched up by a different person than the person that requested/printed the check. All checks that were approved by this department went to a third person in an auditing department who did the sanity check again and also made sure there was money in the contract budget for the check amount.
And we had specific clauses in our contracts to limit our liability for “Errors and Omissions” that were required by our lawyers and business insurance companies.
What I’m saying is that if you’ve got someone in place that’s looking for a loophole to steal money, they’re going to find a way. If the company procedures get in the way, they’ll cheat on personal reimbursements or steal petty cash… or find a way to get kickbacks from contractors for personal recommendations completely outside of your software system.
Create a small background app and let it access the web framework via an API. This app will receive the print job from the web app and send it directly to the printer. That way, the user never “sees” the print data at any point.
It’s true that you have liability for actions you take, but surely that doesn’t extend to malicious activity on the part of your customer. The world will always build better idiots and cannier thieves.
Besides - for a person who has access to check blanks, there is no way to prevent them from printing duplicate checks. Even your current desktop system probably can’t stop someone from printing the imprint information onto a blank sheet of paper and photocopying it onto multiple blanks.
Well - this is the truth. You ARE losing access to certain technologies, while gaining access to ease of software distribution, centralized control of code and data, etc. This is the tradeoff every time you replace desktop software with web-based software.
The only question is whether you decide the tradeoffs are worth it.
Your company may have painted itself into a corner here if your current desktop solution claims to fully address the duplicate check issue (although I would challenge that assertion). Perhaps this would be a good time to pause development and take some time to revaluate moving to the web to make sure it will be able to do what you need it to. As noted by the other posters, there is no way in any web framework to do what you’re looking for here.
The more I think about it, the more I wonder just how many people have access to these check blanks. A more secure system would be to have the blanks kept in a safe that requires two keys to open, thus dividing responsibility for accessing them between two people.
Yes, this is real security risk. Once a person has access to the checks and system, it’s game over. If they want to commit fraud, there is no stopping them. They don’t even need the system. A handwritten check on a pre printed check form is still valid.
QuickBooks online (cloud) allows check printing and there are a whole host of other cloud accounting software systems that face the same challenge. Certainly, they have solved this issue already and modeling your system after theirs would at least be “industry standard”. I suspect they may have taken the approach that it can’t be limited, and the solution is - don’t give access to the system or the checks to people you don’t trust.
The business, not software, needs to ensure there are checks and balances in place to prevent this. For example, someone prints, and another person signs the checks.
