For the past few weeks I've been adding a shopping cart to an existing Domino application. The existing system stored credit card numbers in plain text, which - as I'm sure you know - is a massive huge great no-no when it comes to being PCI DSS compliant.

I'll talk more about how I implemented a gateway part of the cart another day. For now I want to discuss how I avoided, at all costs, storing the credit card number entered by the user.

Normally, to stop a field being saved on the backend document you'd just make it a Computed For Display field, right? Like this:

The field itself is hidden, but we display an input field of the same name to the user using Passthru HTML. This way they can enter a value, we can reference it in our WebQuerySave code and it never gets stored.

Normally it would be as simple as that, but in my case things were complicated. The developer of the existing system had turned on the "Generate HTML For All Fields" Form option. I had no idea why and didn't dare turn it off for fear of what affect this might have on what was already a monstrously-complicated system.

The trouble with the "generate all fields" Form option is that as well as our own PassThru field Domino generates another (type="hidden") one towards the bottom of the HTML form with the same name. It does this because our CFD field is hidden.

When the Form is submitted to the web server the server only accepts the value from the bottom-most field (always ""), so the value entered by the user is never available to us.

To get round this I could use JavaScript to see if there are two fields called CreditCardNumber and, if so, set the value of the second to the value of the first before submitting the form.

var f = document.forms[0];
if (f.CreditCardNumber && f.CreditCardNumber.length>0){
 f.CreditCardNumber[1].value = f.CreditCardNumber[0].value;
}

BUT. Could I live with myself if I was responsible for an e-commerce site that relied on JavaScript to work? Those who know me well enough will know the answer is a resounding NO!!!

The Only Other Solution

My only option was to un-hide the CreditCardNumber field and make it editable. The issue then became how to make sure it never ever ever got stored on the document. To do this I removed it at the very end of the Java WQS agent. Here's how:

public class JavaAgent extends AgentBase {
 private Document document;

 public void NotesMain() {
  try {
   Session session = getSession();
   AgentContext agentContext = session.getAgentContext();
   Database database = session.getCurrentDatabase();
   document = agentContext.getDocumentContext();

   //Do the credit card processing part here.

  } catch(Exception e) {
   e.printStackTrace();
  } finally {
   try{
    document.removeItem("CreditCardNumber");
   }catch(Exception ex) {
    ex.printStackTrace();
   }
  }
 }
}

Notice how we defined the contextual Document outside the NotesMain function? This is so that we can refer to it in the "finally" section. Code inside the "finally" clause will run even if the main code section results in an error for any reason. So, it almost guarantees the field will get removed during saving the document.

Or will it. What if!! What if the Agent fails to run for some reason other than an error in the code? Say the Agent times-out or the server is under heavy traffic and it fails to run completely. What happens then!?

To get round the idea that the Agent might fail to run I added an extra line of @Formula after the call to run the Agent in the Form's WebQuerySave event, like so:

As far as I can tell this is almost fool-proof. What say you? Am I missing something here or can I sleep soundly at night, safe in the knowledge this will always remove the field?