APToolKit (2011) Decrypt when user password is blank but owner password is set
Is there example code for decrypting a PDF file when the user password is not set but the owner password is set?
-
Official comment
Hi BC,
If the User password is blank, use blank string.
int result = toolkit.DecryptPDF(
InputFileName: $"{strPath}owner.pdf",
OutputFileName: $"{strPath}Toolkit.Decrypted.pdf",
UserPassword: "",
OwnerPassword: "ownerpass");
if (result != 0)
{
WriteResult($"Error decrypting PDF: {result}", toolkit);
return;
}You can start with this sample code https://github.com/ActivePDF/Toolkit/blob/master/C%23/Toolkit.EncryptPDF.cs
and modify toolkit.EncryptPDF to toolkit.DecryptPDF as shown above.
Regards,
Mike
ActivePDF Support
Comment actions -
We have a console application C#, .NET Framework 4.7.2. Here is the code we've tried numerous variations without success, we always get -99 as the return value.
Documentation:
DecryptFile
Description
Explicitly decrypts an encrypted PDF.
Return type
Long
Return Value Description- -998 Product not registered/ Evaluation expired.
- -997 Required product version not registered.
- -99 One or more passwords are invalid.
- -98 Input file is not encrypted.
- -3 Unable to access output file.
- -2 Unable to open input file.
- -1 Unable to generate output file.
- 0 Success.
Syntax
object.DecryptFile InputFileName, OutputFileName, UserPassword, OwnerPassword
The DecryptFile method has these required parts:Part Value Type Description
Object An expression of the Toolkit object.
InputFileName String The input filename.
OutputFileName String The output filename.
UserPassword String The case-sensitive password required to open the document.
OwnerPassword String The case-sensitive password required to modify or print the
document.static void Main(string[] args)
{
try
{
string fileName = @"E:\XXX.pdf";
string newName = @"E:\XXXdecrypted.pdf";
var toolkit = new APToolkitNET.Toolkit();
toolkit.SetInputPasswords("", "REMOVED");
var value = toolkit.DecryptFile(fileName, newName, "", "REMOVED");
var info = toolkit.GetPDFInfo(fileName);
var author = toolkit.Author;
var title = toolkit.Title;
var subject = toolkit.Subject;
var keywords = toolkit.Keywords;
var producer = toolkit.Producer;
var creator = toolkit.Creator;
var createDate = toolkit.CreateDate;
var modDate = toolkit.ModDate;
var encryptionError = toolkit.EncryptionError;
var extendedErrorCode = toolkit.ExtendedErrorCode;
var extendedErrorDescription = toolkit.ExtendedErrorDescription;
var extendedErrorLocation = toolkit.ExtendedErrorLocation;
toolkit.CloseInputFile();
toolkit.Dispose();
Console.WriteLine(encryptionError);
Console.WriteLine(extendedErrorCode);
Console.WriteLine(extendedErrorDescription);
Console.WriteLine(extendedErrorLocation);
Console.WriteLine(value);
Console.WriteLine(info);
Console.WriteLine(author);
Console.WriteLine(title);
Console.WriteLine(subject);
Console.WriteLine(keywords);
Console.WriteLine(producer);
Console.WriteLine(creator);
Console.WriteLine(createDate);
Console.WriteLine(modDate);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
if (ex.InnerException != null)
{
Console.WriteLine(ex.InnerException.Message);
}
}
Console.ReadKey();
} -
Hi Mike, thank you for the response.
We have tried a blank string and it still results in the -99 result.
Therefore, maybe it is the ownerPassword that is the culprit.
The ownerpassword used is 37 characters long in the application that is generating the PDF files. Is that a problem? We noticed your documentation states 32 characters max.
Any issue using a console application for our proof of concept work before migrating into our WebApp?
Any other suggestions as to what might be causing us to always get -99 as the return value?
We've spent many hours on this and appreciate any thoughts you have.
PS - I will try the git code you sent and see if it gets me any further and report back. -
FYI no change using this code, still results in -99. We know the password is right, as we copied it directly from the app that generates the PDF files.
string strPath = @"E:\";
string fileName = @"XXX.pdf";
string newName = @"XXX decrypted.pdf";
var toolkit = new APToolkitNET.Toolkit();
int result = toolkit.DecryptFile (
InputFileName: $"{strPath}{fileName}",
OutputFileName: $"{strPath}{newName}",
UserPassword: "",
OwnerPassword: "REMOVED");
if (result != 0)
{
Console.WriteLine($"Error decrypting PDF: {result}", toolkit);
} -
BC, I just saw this
>>The ownerpassword used is 37 characters long in the application that is generating the PDF files. Is that a problem? We noticed your documentation states 32 characters max.
That is likely the source of the trouble.
Mike - We created a PDF with a 32 character ownerPassword and the result is still -99.
-
>>We know the password is right, as we copied it directly from the app that generates the PDF files.
Are you able to change the owner password using Acrobat?
Mike - I do not have Acrobat Pro therefore I am not sure I can change the owner password? I cannot even find where to enter it. With that said, we did attempt to set the UserPassword in our web app that generates PDF files and then opened it in Acrobat using the password we set for the UserPassword successfully.
Leads me to believe there is some issue with our configuration/code that is preventing APToolKit from opening/decrypting the PDF's we are generating.
I know the Acrobat SDK uses a standard, so if Acrobat can open our PDF's we're generating and the permissions are correct, I'd have to assume that APToolKit should be able to as well.
Here is a screen shot of one of our PDF's, you can see it is "SECURE", it has the permissions set to Printing only, the Document Open Password is NO, the Permission Password is YES.
We're baffled...
-
BC, Let's take this offline. Please open ticket https://support.activepdf.com/
and include your code.cs file and an example PDF file. We'll run it through 2011 R4.3 and get this sorted out.
-Mike
-
BC, Let's take this offline. Please open ticket https://support.activepdf.com/
and include your code.cs file and an example PDF file. We'll run it through 2011 R4.3 and get this sorted out.
-Mike
Done. Thank you Mike.
Please sign in to leave a comment.
Comments
12 comments