Does anyone know how to decode the encoded string in IBM task route exported template file? I tried various ways of decoding such as Base64, none of them worked on the encoded string. a screenshot of part of the encoded string is as below. Thanks!
<config>
<Name><![CDATA[FSC Metadata File Collector]]></Name>
<Description><![CDATA[This collector finds metadata files from specified directories according to filter criteria, submits the files described in the metadata file, and then submits the metadata file. .]]></Description>
<ConnectorTypeKey>ibm.ctms.filesystem.Connector</ConnectorTypeKey>
<TypeKey><![CDATA[ibm.ctms.filesystem.metadata_collect]]></TypeKey>
<IsActive>1</IsActive>
<TaskRouteId>46f15f20-5b89-4e89-9ea0-4051e62f44d8</TaskRouteId>
<ScheduleConfiguration>UDC4aQAAAAAAAAAAbABhAEAwuGlfAGwA4wcIAHQAHAAOAAwADABrAOMHCAB0ABwADgAMAAwAawAAAAAAAAAAAA==</ScheduleConfiguration>
<Configuration>FgAAAHNlcmlhbGl6YXRpb246OmFyY2hpdmUIAAQEBAgBAAAAAAEAAAAABAAAAAEAAAAAAQAAAEQAAABcAFwARQBQAFMARQBDAE0AWgBcAEQAYQB0AGEAXABEAGEAdABhAF8AMQBcAEMAbwBuAHQAZQBuAHQAXABJAE0AQgBcADAAYgB5AHQAZQBzAFwARQBQAFMARQBDAE0AegBDAG8AbABsAGUAYwB0AG8AcgBcAEkAbgBwAHUAdABGAGkAbABlAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAHgAAAAYAAABTAG8AdQByAGMAZQAkAAAAOAA5ADIANgBmADYAMgA4AC0AZAA3ADUAOAAtADQAOAAxAGUALQA4ADgAMgA2AC0AYQA1AGMAZABkAGMANwA2AGMAZgA4ADgAAQADAAAAJAAAADgAOQAyADYAZgA2ADIAOAAtAGQANwA1ADgALQA0ADgAMQBlAC0AOAA4ADIANgAtAGEANQBjAGQAZABjADcANgBjAGYAOAA4AAAAAAAAAAAADQAAAAABAAAABgAAAAAAAAAADAAAAEMAcgBlAGEAdABpAG8AbgBEAGEAdABlAAwAAABDAHIAZQBhAHQAaQBvAG4ARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAHQAAAC8AeABtAGwALwBGAGkAbABlAC8AQwByAGUAYQB0AGkAbwBuAEQAYQB0AGUALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAHAAAAQwByAGUAYQB0AG8AcgAHAAAAQwByAGUAYQB0AG8AcgAAAAAAAAAAABgAAAAvAHgAbQBsAC8ARgBpAGwAZQAvAEMAcgBlAGEAdABvAHIALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAJAAAARABvAGMAUwB0AGEAdAB1AHMACQAAAEQAbwBjAFMAdABhAHQAdQBzAAAAAAAAAAAAGgAAAC8AeABtAGwALwBGAGkAbABlAC8ARABvAGMAUwB0AGEAdAB1AHMALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAIAAAARABvAGMAVABpAHQAbABlAAgAAABEAG8AYwBUAGkAdABsAGUAAAAAAAAAAAAZAAAALwB4AG0AbAAvAEYAaQBsAGUALwBEAG8AYwBUAGkAdABsAGUALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAIAAAARABvAGMAdQBtAGUAbgB0AAgAAABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAZAAAALwB4AG0AbAAvAEYAaQBsAGUALwBEAG8AYwB1AG0AZQBuAHQALwB0AGUAeAB0ACgAKQAGAAAAAAAAAAAQAAAATABhAHMAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAQAAAATABhAHMAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAIQAAAC8AeABtAGwALwBGAGkAbABlAC8ATABhAHMAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAvAHQAZQB4AHQAKAApAAUAAAAAAAAAAAwAAABMAGEAcwB0AE0AbwBkAGkAZgBpAGUAcgAMAAAATABhAHMAdABNAG8AZABpAGYAaQBlAHIAAAAAAAAAAAAdAAAALwB4AG0AbAAvAEYAaQBsAGUALwBMAGEAcwB0AE0AbwBkAGkAZgBpAGUAcgAvAHQAZQB4AHQAKAApAAYAAAAAAAAAABcAAABSAGUAdABlAG4AdABpAG8AbgBJAG4AaQB0AGkAYQB0AGkAbwBuAEQAYQB0AGUAFwAAAFIAZQB0AGUAbgB0AGkAbwBuAEkAbgBpAHQAaQBhAHQAaQBvAG4ARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAKAAAAC8AeABtAGwALwBGAGkAbABlAC8AUgBlAHQAZQBuAHQAaQBvAG4ASQBuAGkAdABpAGEAdABpAG8AbgBEAGEAdABlAC8AdABlAHgAdAAoACkABQAAAAAAAAAABgAAAFMAbwB1AHIAYwBlAAYAAABTAG8AdQByAGMAZQAAAAAAAAAAABcAAAAvAHgAbQBsAC8ARgBpAGwAZQAvAFMAbwB1AHIAYwBlAC8AdABlAHgAdAAoACkABQAAAAAAAAAACgAAAFQAYQByAGcAZQB0AFAAYQB0AGgACgAAAFQAYQByAGcAZQB0AFAAYQB0AGgAAAAAAAAAAAAbAAAALwB4AG0AbAAvAEYAaQBsAGUALwBUAGEAcgBnAGUAdABQAGEAdABoAC8AdABlAHgAdAAoACkABQAAAAAAAAAABAAAAFQAeQBwAGUABAAAAFQAeQBwAGUAAAAAAAAAAAAVAAAALwB4AG0AbAAvAEYAaQBsAGUALwBUAHkAcABlAC8AdABlAHgAdAAoACkABQAAAAAAAAAAEQAAAFAAcgBvAGMAZQBzAHMAaQBuAGcAVAByAGkAZwBnAGUAcgARAAAAUAByAG8AYwBlAHMAcwBpAG4AZwBUAHIAaQBnAGcAZQByAAAAAAAAAAAAHwAAAC8AeABtAGwALwBGAGkAbABlAC8AUAByAG8AYwBlAHMAcwBUAHIAaQBnAGcAZQByAC8AdABlAHgAdAAoACkABgAAAAAAAAAADwAAAFMAZQB0AE0AbwBkAGkAZgBpAGUAZABEAGEAdABlAA8AAABTAGUAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAIAAAAC8AeABtAGwALwBGAGkAbABlAC8AUwBlAHQATQBvAGQAaQBmAGkAZQBkAEQAYQB0AGUALwB0AGUAeAB0ACgAKQAAAAAAAQEGAAAAUwBvAHUAcgBjAGUAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</Configuration>
<ParameterMappings>
</ParameterMappings>
</config>
sample encoded strings
Related
I have two instances where I'm converting a TIFF file before sending the data to google vision AI. Using CLI, the base64 string works fine. I get the expected response
When I use Java I'm getting a different out, which causes my API call to fail. The base64 output is different.
// API call https://vision.googleapis.com/v1/files:annotate
imageBytes = Files.readAllBytes(new File(fileLocation).toPath());
String imageString = Base64.getEncoder().withoutPadding().encodeToString(imageBytes);
// API response "message": "Unsupported input file format."
I'm looking for suggestions on how to convert a file (tiff, pdf, png) to base64 using plain Java
In Esign version 4.1.1, the VS2019 Docusign project code generators produce this type of config file:
Note that the developer must copy and paste the private key generated on the DocuSign "Quick Start" page into the VS2019 Docusign Project Wizard. The key is converted into a string, with each line in the original key file represented with a carriage return.
Using the private key value in this fashion, inline, with all the other params was very convenient.
This "RSAKey" param value does work with the 4.1.1 version. But does not with the 5.2 version.
In the Esign 5.2 version, we are now in the Asp.Net Core 3.1/.NET 5 style of code, so we now have this configuration file format:
This won't work with Esign 5.2. I surmise the change in 5.2 is this - the Docusign server generates a hash value of the key file, and if the generated hash of the key file submitted by an external client does not match, an "Unknown PEM File" error is sent back. I am trying to highlight the nuance that the first “gate” on the DocuSign server checks the file itself, not the RSA key inside the file.
The ramification, if true, is that we now have to treat the key file with kid gloves. If I wanted to store/retrieve this file from a remote source, I would need to take great care that not a single byte was changed/added/removed. This will require careful testing. As you can see from my sample appsettings.json above, I am forced to add "KeyFilePath" param in order to grab the physical file, which means I must always have it on hand in my project or be able to remotely load it (intact byte-wise) from a remote source. This increases the burden on the developer and maintenance staff considerably.
Ideally, what we need is a way to get that capability to put the key-file-as-a-string back into the config params.
Any ideas appreciated.
One way to solve this is by using https://base64.guru/ .
Using the "File-to-Base64" option allow me to provide this as a string parameter in a normal config file.
Then the C# code to use it looks like this:
var cred = LoadDocusingConfigIntoObject();
byte[] buffer = Convert.FromBase64String(cred.PrivateKey);
this.OAuthToken = docusignClient.RequestJWTUserToken(
cred.IntegrationKey,
cred.ImpersonatedUserId,
cred.AuthServer,
buffer,
1,
scopes
);
I wanted to extract PDF content using Apache Tika Library. All is good until I encountered PDF with encrypted username and password.
It hits errors as below:
INFO Document is encrypted
org.apache.tika.exception.EncryptedDocumentException: Unable to process: document is encrypted
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:153)
Caused by: org.apache.pdfbox.exceptions.CryptographyException: Cannot find an appropriate security handler for Adobe.APS
at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:952)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:139)
... 4 more
Does anyone knows if Apache Tika supports extraction of PDF with such security feature?
You can try it below. It worked for me
PasswordProvider pp = (metadata) -> "password";
// Create a context parser for the pdf document
ParseContext context = new ParseContext();
context.set(PasswordProvider.class, pp);
When I work with Firebase Storage I use downloadURL file metadata to access the file. But the documentation says it's downloadURLs. Is that a typo?
It says that downloadURLs is an Array of strings.
From experience, Firebase lets you create new Download Urls so that single files can have multiple download URLs.
It is mentioned on the documentation that the downloadURLs variable is:
An array of long-lived download URLs. Always contains at least one
URL.
downloadURL is a different variable. If you get the downloadURL programmatically using getDownloadUrl(), it will generate a new url that will be added to the downloadURLs array. But if you get it from the metadata, it will give you an URL that already exists on that array.
public void ZipExtract(Stream inputStream, string outputDirectory)
{
using (ZipFile zip = ZipFile.Read(inputStream))
{
Directory.CreateDirectory(outputDirectory);
zip.ExtractSelectedEntries("name=*.jpg,*.jpeg,*.png,*.gif,*.bmp", " ", outputDirectory,
ExtractExistingFileAction.OverwriteSilently);
}
}
[HttpPost]
public ContentResult Uploadify(HttpPostedFileBase filedata)
{
var path = Server.MapPath(#"~/Files");
var filePath = Path.Combine(path, filedata.FileName);
if (filedata.FileName.EndsWith(".zip"))
{
ZipExtract(Request.InputStream,path);
}
filedata.SaveAs(filePath);
_db.Photos.Add(new Photo
{
Filename = filedata.FileName
});
_db.SaveChanges();
return new ContentResult{Content = "1"};
}
I try to read zip archive from stream and extract files. Got the following exception in the line "using (ZipFile zip = ZipFile.Read(inputStream))" : ZipEntry::ReadDirEntry(): Bad signature (0xC618F879) at position 0x0000EE19
Any ideas how to handle this exception?
The error is occurring because the stream you are trying to read is not a valid zip bytestream. In most cases, Request.InputStream will not represent a zip file. It will represent an HTTP message, which will look like this:
POST /path/for/your/app.aspx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.2; ...)
Content-Type: application/x-www-form-urlencoded
Content-Length: 11132
...more stuff here...
I think what you are doing is trying to read that message as if it were a zip file. That's not gonna work. The file content is actually embedded in the "... more stuff here..." part.
To work toward solving this, I suggest you work in smaller steps.
First, get the file upload to work, saving the content of the uploaded file to a filesystem file on the server. Then, on the server, try to open the file as a zipfile. If it works, then you should be able to replace the file saving portion, with ZipFile.Read(). If you cannot open the file that you saved, then it means that the file that you saved is not a zip file. Either it is incomplete, or, more likely, it includes extraneous data, like the HTTP headers.
If you have trouble successfully uploading a binary file like a zip file, first work on uploading a text file. You can more easily verify the upload of a text file on the server, by simply opening the uploaded content in a text editor, and checking that it contains exactly the content of the file that was uploaded from the client. Once you have this working, move to a binary file. Then you can move to a full streaming approach, using DotNetZip to read the stream. Once you get to this point, there should be no need to save the file to the filesystem, before reading it as a zip file, but you may want to save it anyway, for other reasons.
To help, you may want to use Fiddler2, the debugging HTTP proxy. Install it on the browser machine, turn it on, and it will help you see the messages that get sent from the browser to the ASPNET application on the server. You'll see that a file upload contains more that just the bare file data.
A more stable solution could be to use ICSharpCode ZipLib: http://www.sharpdevelop.net/OpenSource/SharpZipLib/Default.aspx