Skip to main content

Hello All,

 

Our customer wishes to use digital signature functionality so they have created a new custom event action for event DOCUMENT_APPROVED. 

Method:

Edm_File_Sign_Util_API.Certify_Pdf_File (‘&DOC_CLASS', '&DOC_NO', '&DOC_SHEET' , '&DOC_REV' , 'Signature from IFS');

 

They have generated new user certificates in keystores window and when the user try to approve the document, below error “Invalid file name” comes.

As you can see there are no special characters in the file name. When I check the application message I can see the same error message there.

The message request xml is in correct form and has valid structure. 

<DOCDIGITALSIGNATURE_CERTIFYPDFFILE_REQUEST>
<DOC_CLASS>XYZ.01</DOC_CLASS>
<DOC_NO>COVA-111</DOC_NO>
<DOC_SHEET>1</DOC_SHEET>
<DOC_REV>02</DOC_REV>
<DOC_TYPE>VIEW</DOC_TYPE>
<FILE_NO>1</FILE_NO>
<REASON>Signature from IFS</REASON>
</DOCDIGITALSIGNATURE_CERTIFYPDFFILE_REQUEST>

What would be the reason for the error in the app message and any hints to debug it further is appreciated.

 

Thanks

Amila

I think I have seen that error before but I don't remember what the reason for it can be.

This is a long shot, but what if the extra period in the file name there ("EB.02" and "XYZ.01") is not handled correctly in the digital signer (or Docman)?

Is it possible for you to try with a document class that does not include a period? It should of course work with period in any of the document keys, but it would be good if we can try that theory out.
 

Hi @Mathias Dahl Thanks for the reply but I have already tried with a doc class like EB.02 with a period in our internal environments and I could not recreate the error there. So it cannot be that. Is there any other logs that we can check to get further idea about the error?

@Daniel Svantesson Any ideas on what “Invalid file name” above could mean? Is it from the PDF signing code you think?

 

PS. Did a quick code search. Could not find that error message in Docman nor the framework… Could be from one of the libs used by the framework signing code perhaps…

 

 

Hi @Mathias Dahl 

Customer get back to me with new test results and they still get the error even after trying with new doc class which has only English letters (XYZ) and same for file name as well (TESTDOC.pdf).

 

I did a code search for “Invalid file name” and I got a hit in DOCMAN in below file. Is it relevant in this process?

docman\source\docman\server\packages\DocumentStorageUtility\ifs\application\documentstorageutility\impl\DocumentStorageServiceImpl.java

@Amila Samarasinghe 

Thanks! Missed that for some reason... It might be related, yes, since that file name validation there is used both when reading and writing files in Docman. The validateFileName method in there is some sort of protection against hackers trying to use "clever" file names in order for bad things to happen at the server. Why it would fail in this case I cannot say. If there is an error when reading that file in the PDF signing flow, there should also be an error when you just try to view the file.

Hi @Mathias Dahl 

After examining logs and reading through java code, I was able to figure out the issue. The problem was that in customer VM, the path for environment variables TEMP and TMP were somewhat longer and also it contained underscore character. Somewhere in the java code it creates a temp file and it gets saved in TEMP folder defined in env variables and then inside validateFileName method, the conditions fails and hence the error.

It works for simple paths like C:\Windows\Temp

 

Thanks

Aaahh... Thanks for digging into this and reporting back!

Or sounds like a bug not being able to have an underscore in the temporary path name. Easily worked around once you know it, of course.

Report a case about this if you like and we can fix it.

Or just use the workaround 😀 My guess is a fix will benefit very few customers.

 

Hi @Mathias Dahl 

Yes I will report a case so that we can get a bug fix :) 

Thanks

Terms & ConditionsCookie settings