I'm encrypting a file and saving it in AWS. What Media Type (FKA MIME-type) is encrypted text? "text/plain" doesn't seem right.
Use
application/octet-stream
which is intended for arbitrary binary data - perfect for an encrypted file that by definition can't be interpreted. (RFC2046)
Related
The problem
1- I'd like to create a MIME message. Something like this:
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="---12345"
This is a multipart message in MIME format.
---12345
Content-Type: text/plain
This is the plain text
---12345
Content-Type: application/pdf
>> PDF binary code here <<
---12345
2- Then i need to pass it to the OpenSSL functions in the form of BIO * data.
PKCS7 *PKCS7_sign(..., ..., ..., BIO *data, ...);
The first approach
Load the plain text and attachment data from the filesystem and assign it to char * data, manipulate the data to add the respective MIME headers, finally assign it to BIO * memoryBIO with BIO_puts(memoryBIO, data);.
But this approach doesnt work because the binary data contains "\0"(NULL) which wont go well with char type.
The second approach
Assign plain text and attachment to a BIO each and then "concatenate" them. But couldn't find a way to do this.
Conclusion
I'd like to know if there is a way to accomplish such feat.
I'd also like to avoid using intermediary files and build everything in-memory.
After following jww's suggestion, what i ended up using is BIO_write();.
BIO * inBIO = NULL;
std::vector<unsigned char> data = GetData();
inBIO = BIO_new(BIO_s_mem());
BIO_write(inBIO, data.data(), data.size());
Again thanks to jww for this answer and for all the other answers regarding OpenSSL in SO, you've helped me a great deal.
I am unable to open a base64 string as pdf in angular application if the file size is more than say 10mb. The browser crashes with a page saying "AW, SNAP". The base64 string i.e. "base64content" already has the metadata at the start and looks something like this:
data:application/pdf;base64,JVBERi0xLjQK...DUKJSVFT0YK
I am using below way to open the base64 string as a PDF in new tab:
$window.open(base64content);
Try with
window.open('data:application/pdf;base64,' + base64content);
This happened because the base64 string was too big for the browser to interpret. This is because the pdf was heavy(more than 2mb) the approx max limit of browser. The solution was to use blob based approach.
Please be patient and check this problem.
I wrote some simple PHP code for uploading images.
Here is the code (snippets)
<?php
header('Content-Type: text/plain; charset=utf-8');
//set encoding for prepared statements
$dbh->exec("SET NAMES UTF8");
$dbh->query('SET NAMES UTF8');
//check if file is actually an image etc.
//send image to "upload" folder
move_uploaded_file($_FILES["file"]["tmp_name"],"upload/" . $_FILES["file"]["name"]);
//save to the database a string like "upload/myImage.jpg", so I can render it on the site later
$stu = $dbh->prepare("UPDATE multi SET m_place=:name WHERE m_id = :id");
$stu->bindParam(':name', $n, PDO::PARAM_STR);
$n= "upload/".$_FILES["file"]["name"];
$stu->execute();
If the name of the image is in English, everything is fine. If is in Greek, it saved ok in the database , but not in the folder. In the database I see χωρις τιτλο.jpg (which is right) and in the folder χωΟΞ―Ο‚ τίτλο.jpg which is wrong.
I've tried everything and cannot fix this. To get the right titles in the folder.
The encoding of the database (postgreSQL 9.1) is UTF8, the Collation and the Character Type are Greek_Greece.1235. The collaction in table's column which I save the image's title is pg_catalog."C".
I use DreamWeaver. The file that handles the uploads is a php file. Encoding is utf8, Unicode Normalization Form is C and the Include Unicode Signature (BOM) is unchecked.
The default language is Greek in Region and Language in the control panel. (Windows 7 Home Premium)
The encoding of the browser is utf8
I also use Apache 2.2.22. Is it Apache's fault? Or its the php file? Or the database?
I dont know what else to do...What am I missing? Please please please advice
This seems to be a StackOverflow issue and not related to ServerFault. However, you should take a look at this post:
For naming files in UTF-8:
Can a PHP file name (or a dir in its full path) have UTF-8 characters?
For writing files in UTF-8:
How to write file in UTF-8 format?
Turns out , I had not tried everything.
Thanks to this I found the solution.
It has to do with PHP and how "PHP filesystem functions can only handle characters that are in system codepage"
So I used the iconv function.
I changed the code like so
move_uploaded_file($_FILES["file"]["tmp_name"],"upload/" . iconv('UTF-8', 'Windows-1253',$_FILES["file"]["name"]));
For the application using japanese, the code page is cp932
This can be comfirm by using chcp command in commandline.
Sample Code
$fullPath = $uploadFolderPath."\\".iconv("utf-8", "cp932", $fileName);
move_uploaded_file($this->request->data["file_name"]['tmp_name'], $fullPath);
I have been struggling with some very basic understanding of how google app engine store data
I have defined a class defining a client profile as such :
class ClientProfile(ndb.Model):
nickname = ndb.StringProperty(required=True)
photo = ndb.BlobProperty()
uuid = ndb.StringProperty(required = True)
I retrieve an image data only uploading image.src via a POST using jquery.ajax(...)
The data are properly sent to Google app engine and I can assign them to a variable with
imagesrc = self.request.get('photosrcbase64')
The data content is something looking like :
"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...
So fare so good, the data is an image/png and the encoding is Base64, but should I care if it end in a Blob ?
Now if I try to put the data in the photo Blob
with for example :
clientprofile.photo = imagesrc I get a Bad Value Error, in this case :
BadValueError: Expected str, got
u'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMgAA
I tried all kind of combinations using different solutions and get back all kind of BadValue or type errors.
My question are :
1) Why does the Blob care, if it is a binary storage, I should be able to dump in it anything without having to interpret it and/or convert it, so is a Blob really a Binary/Raw storage and why does it care about how things are stored in it ?
2) I have started having problems with this 2 years ago when still using db instead of ndb, I found a solution that I did not understand by stripping out the MIME information at the beginning of the data string, decoding the string Base64 and using db.Blob(...) to convert my string to a Blob. the problem is that db.Blob() does not seem to exist in ndb so I can't do this any more.
I am convinced that I am missing something fundamental in the way informations are exchanged between google app engine and the browser and thank you in advance for a mind clearing answer
A BlobProperty is meant to be binary data. The str type in Python is fully equivalent to a byte string since the only characters allowed are
[chr(byte_value) for byte_value in range(2**8)]
So before storing the value from self.request.get('photosrcbase64'), which is of type unicode, you'll need to cast to type str.
You can do this either by directly doing so
imagesrc = str(self.request.get('photosrcbase64'))
or first trying to decode to ascii.
I'm trying to read a JPEG file stored in the GAE blobstore back into a byte array using the following code:
info,_ := blobstore.Stat(context,appengine.BlobKey(request.FormValue("blobkey")))
image := make([]byte,info.Size)
reader := blobstore.NewReader(context,appengine.BlobKey(request.FormValue("blobkey")))
n,nerr := reader.Read(image)
The image is stored correctly i.e. it can be served using blobstore.Send(...).
And the above code sort of works (in that it does read back the blob data) but it converts any 0x0a byte into a 0x0d 0x0a pair (i.e. LF into CR LF).
Is there a way in Go to work around this behaviour (without writing a filter to convert 0x0d0a back to 0x0a) ?
EDIT:
It turns out the problem is not with Blobstore.Reader at all, but with the attachment encoding in mail.py on the dev appserver.
The mail attachment handling on the dev appserver does not correctly encode image data. If the attachment data is known to be binary, a partial workaround is to add the line:
encoders.encode_base64(mime_attachment)
after the line
mime_attachment.set_payload(attachment.data())
in the file
google/appengine/api/mail.py
Using a MIMEImage attachment for an image content type would be a better solution but causes a 'LazyImporter object is not callable' error.