You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Manuel López Blasi <lo...@conicet.gov.ar> on 2018/01/16 14:52:19 UTC
exportDocumentView-ImportXml corrupted encrypted file
Hi everyone,
i'm using the Export/Import feature, methods from Session. It backups
nodes / subtrees to an xml file.
I'm also backing up Binary values, wich are encrypted pdf files.
to backup:
session.exportDocumentView(path, FileOutputStream, false,false);
to restore:
session.getWorkspace().importXML(path,FileInputStream,ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
Now, when i try to decrypt the Binary property of my nodes, i get the
following exception:
Severe: javax.crypto.BadPaddingException: Given final block not properly
padded
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:313)
at javax.crypto.Cipher.doFinal(Cipher.java:2131)
at
ar.gov.conicet.apps.sigerh.util.crypto.CFileEncryptor.hacerEncriptacion(CFileEncryptor.java:38)
Any ideas on how to overcome this?
Thanks in advance,
cheerz.
Re: exportDocumentView-ImportXml corrupted encrypted file
Posted by Manuel López Blasi <lo...@conicet.gov.ar>.
I'm doing some tests right now, i believe it has something to do with
encoding, maybe binary to string/text conversion.
I had problems with FOP in the past, where i had to read the stylesheets
and explicitly treat them as UTF-8 , otherwise the XLST processor
would crash.
Without this trick FOP pdf's would be no more, maybe this is the same
case (???) :
String hojaEstilo = getStyleSheet(SXSL);
byte[] contenido = hojaEstilo.getBytes("UTF-8");
stream = new
CUFopProcess().renderXmlFromByteArrays(xml
.toString().getBytes("UTF-8"),
contenido, SXML);
I'm using embedded jackrabbit-2.14.4 inside Glassfish 3.1.2 through
jackrabbit-jca-connector 2.14.4 (have connection pool and JNDI resource
setted up ),
and finally through jackrabbit OCM 2.0 . Nothing else in between. We're
just storing files in the datastore, only pdf files.
On 16/01/18 16:31, Julian Reschke wrote:
> On 2018-01-16 15:52, Manuel López Blasi wrote:
>> Hi everyone,
>>
>> i'm using the Export/Import feature, methods from Session. It backups
>> nodes / subtrees to an xml file.
>> I'm also backing up Binary values, wich are encrypted pdf files.
>> ...
>
>
> FWIW; what Jackrabbit version are you using, and how do you connect to
> the store? Is there WebDAV remoting involved?
>
Re: exportDocumentView-ImportXml corrupted encrypted file
Posted by Julian Reschke <ju...@gmx.de>.
On 2018-01-16 15:52, Manuel López Blasi wrote:
> Hi everyone,
>
> i'm using the Export/Import feature, methods from Session. It backups
> nodes / subtrees to an xml file.
> I'm also backing up Binary values, wich are encrypted pdf files.
> ...
FWIW; what Jackrabbit version are you using, and how do you connect to
the store? Is there WebDAV remoting involved?
Re: exportDocumentView-ImportXml corrupted encrypted file
Posted by Julian Reschke <ju...@gmx.de>.
Can you do a file comparison between original and corrupted? Prime
suspect would be something treating binaries as text, converting line
ends...
On 2018-01-16 20:15, Manuel López Blasi wrote:
> I tried with unencrypted pdf files, it breaks them too.
>
> I noticed the files are slightly bigger (10kb) when restored from xml.
> All the nodes and structure is there, but all Binary are corrupted. At
> least with pdf files, maybe plain text or other kind of
> files do fine. I've read somewhere it's related to base64 encoding wich
> is what the exporter seems to use for storing binary
> in xml file.
>
> Notice that this are JCR methods (javax.jcr.Session and
> javax.jcr.Workspace), not Jackrabbit related.
>
>
> On 16/01/18 12:28, Julian Reschke wrote:
>> On 2018-01-16 15:52, Manuel López Blasi wrote:
>>> Hi everyone,
>>>
>>> i'm using the Export/Import feature, methods from Session. It backups
>>> nodes / subtrees to an xml file.
>>> I'm also backing up Binary values, wich are encrypted pdf files.
>>>
>>> to backup:
>>>
>>> session.exportDocumentView(path, FileOutputStream, false,false);
>>>
>>> to restore:
>>>
>>> session.getWorkspace().importXML(path,FileInputStream,ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
>>>
>>>
>>>
>>> Now, when i try to decrypt the Binary property of my nodes, i get the
>>> following exception:
>>>
>>>
>>> Severe: javax.crypto.BadPaddingException: Given final block not
>>> properly padded
>>> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
>>> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
>>> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:313)
>>> at javax.crypto.Cipher.doFinal(Cipher.java:2131)
>>> at
>>> ar.gov.conicet.apps.sigerh.util.crypto.CFileEncryptor.hacerEncriptacion(CFileEncryptor.java:38)
>>>
>>>
>>> Any ideas on how to overcome this?
>>>
>>>
>>> Thanks in advance,
>>> cheerz.
>>
>> That sounds like a bug. Can you submit a JIRA ticket and attach a test
>> case?
>>
>> Best regards, Julian
>>
>
>
Re: exportDocumentView-ImportXml corrupted encrypted file
Posted by Manuel López Blasi <lo...@conicet.gov.ar>.
I tried with unencrypted pdf files, it breaks them too.
I noticed the files are slightly bigger (10kb) when restored from xml.
All the nodes and structure is there, but all Binary are corrupted. At
least with pdf files, maybe plain text or other kind of
files do fine. I've read somewhere it's related to base64 encoding wich
is what the exporter seems to use for storing binary
in xml file.
Notice that this are JCR methods (javax.jcr.Session and
javax.jcr.Workspace), not Jackrabbit related.
On 16/01/18 12:28, Julian Reschke wrote:
> On 2018-01-16 15:52, Manuel López Blasi wrote:
>> Hi everyone,
>>
>> i'm using the Export/Import feature, methods from Session. It backups
>> nodes / subtrees to an xml file.
>> I'm also backing up Binary values, wich are encrypted pdf files.
>>
>> to backup:
>>
>> session.exportDocumentView(path, FileOutputStream, false,false);
>>
>> to restore:
>>
>> session.getWorkspace().importXML(path,FileInputStream,ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
>>
>>
>>
>> Now, when i try to decrypt the Binary property of my nodes, i get the
>> following exception:
>>
>>
>> Severe: javax.crypto.BadPaddingException: Given final block not
>> properly padded
>> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
>> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
>> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:313)
>> at javax.crypto.Cipher.doFinal(Cipher.java:2131)
>> at
>> ar.gov.conicet.apps.sigerh.util.crypto.CFileEncryptor.hacerEncriptacion(CFileEncryptor.java:38)
>>
>>
>> Any ideas on how to overcome this?
>>
>>
>> Thanks in advance,
>> cheerz.
>
> That sounds like a bug. Can you submit a JIRA ticket and attach a test
> case?
>
> Best regards, Julian
>
Re: exportDocumentView-ImportXml corrupted encrypted file
Posted by Julian Reschke <ju...@gmx.de>.
On 2018-01-16 15:52, Manuel López Blasi wrote:
> Hi everyone,
>
> i'm using the Export/Import feature, methods from Session. It backups
> nodes / subtrees to an xml file.
> I'm also backing up Binary values, wich are encrypted pdf files.
>
> to backup:
>
> session.exportDocumentView(path, FileOutputStream, false,false);
>
> to restore:
>
> session.getWorkspace().importXML(path,FileInputStream,ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
>
>
>
> Now, when i try to decrypt the Binary property of my nodes, i get the
> following exception:
>
>
> Severe: javax.crypto.BadPaddingException: Given final block not properly
> padded
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:313)
> at javax.crypto.Cipher.doFinal(Cipher.java:2131)
> at
> ar.gov.conicet.apps.sigerh.util.crypto.CFileEncryptor.hacerEncriptacion(CFileEncryptor.java:38)
>
>
> Any ideas on how to overcome this?
>
>
> Thanks in advance,
> cheerz.
That sounds like a bug. Can you submit a JIRA ticket and attach a test case?
Best regards, Julian