What's the proper process to follow when signing an Oauth 1.0 request that includes files? Do you include the file for the hash calculation or just some key of it? Or is it omitted entirely?
You only need to include parameters in the signature base string with a content-type of application/x-www-form-urlencoded. Your file upload is going to be multipart/form-data so you don't need to include any part of the file for the signature calculation. See here for more information.
Related
I have found documentation for uploading an image from iOS to a blob container in Azure - https://learn.microsoft.com/en-us/azure/storage/blobs/storage-ios-how-to-use-blob-storage
using the https://github.com/Azure/azure-storage-ios library
But I wish to upload directly to a file share. Is there a way to do this?
It needs to be implemented using SAS authentication.
Unfortunately I am not familiar with iOS programming thus I will not be able to provide you any code. However you can use the steps below to write code.
Assuming you have a SAS URL for the file share in which you wish to upload the file, you can simply use Azure Storage REST API to upload the file in a file share. You should be able to use built-in HTTP functionality in the programming language of your choice to do that.
Let's assume that you have a SAS URL for the file share in the following format: https://<account-name>.file.core.windows.net/<share-name>?<sas-token>.
First thing you would need to do is insert the file name that you wish to upload in this SAS URL so that you get a SAS URL for the file. Your SAS URL would look something like: https://<account-name>.file.core.windows.net/<share-name>/<file-name>?<sas-token>.
Next you would need to create an empty file. You will use Create File REST API operation. Do not worry about the Authorization request header there as it is already included in the SAS. Only request header you would need to include is x-ms-content-length value of which should be the size of the file you want to upload. This will create an empty file having size as that of the file you want to upload.
Once this operation completes, next you would need to upload the data in the empty file you just created. You will use Put Range operation. The request headers you need to include are x-ms-range (value of which should be bytes=0-file-length - 1) and Content-Length (value of which should be the length of your file). The request body will contain the file contents.
Using these steps you should be able to upload a file in a file share.
I am trying to send a vcard via Twilio when a subscriber is added to my mailchimp list. I am using zapier for the integration. All the steps work, except when adding the vcard.
When the message is sent I get the following error message: "Twilio is unable to process the Content-Type of the provided URL. Please see the Twilio Markup XML Documentation for more information on valid Content-Types."
I understand that vcard/text is a supported type. the file is stored at https://gallery.mailchimp.com/485f8f63814a122cf8435a4ee/files/cd3791fc-83c0-469a-9029-a4a0341fe82f/johnmenke.vcf
Twilio seemed to pick up the file and read the information (the text is dsiplayed in my account), can anyone help me understand what I have wrong? I'm in the US, in case that matters.
Thank you!
Twilio developer evangelist here.
I just curled that URL and the response content type was Content-Type: application/octet-stream which is not a supported MIME type.
If you serve the file as text/vcard it should be fine. You may find that where you have hosted it can't provide the right response content type, so you may need to host it elsewhere.
If you are using nginx to serve files, you may need to add the vcard as a mime type. Some installations of nginx do not have vcard as a default mime type. For example, your nginx.conf file may contain a line like the following:
include /etc/nginx/mime.types;
And you will want to add the vcard mime type, so just append the following lines to the nginx.conf file:
types {
# here are additional types
text/vcard vcard vcf;
}
I want to access https://editor.swagger.io/ but need the YAML file to be preloaded based on a URL parameter.
So if I want to view https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml, I should be able to provide this as an input to swagger editor accessible over the internet.
Is this possible?
Yes, Swagger Editor supports the url parameter:
https://editor.swagger.io/?url=https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml
Note that to load OpenAPI files from GitHub/GitLab/Bitbucket/etc., you need to specify the "raw" file link.
Also, for this to work, the server where the YAML/JSON file is hosted must use HTTPS and support CORS (i.e. allow cross-domain calls from editor.swagger.io).
I want to upload a text file to OneDrive API.I don't have any idea about multipart/related. Can any one suggest me how to put below data in postman to upload a file.
I resolved this issue.We need to provide Authorization & Content-Type in header and provide the remaining information in body as raw and select content-type as Text.
I am generating pdf using wicked_pdf and I am also using prawntable for pdfs which needs to be password protected. Since wicked pdf doesnt supports password protected pdf generation.
Is there any way to add a digital signature which is in .pfx format to pdf.?
Passwording pdf files vs digitally signing them
Passwording a pdf file encrypts the file. You will need to find a pdf library/toolkit to do that for you. If you can't find one with a ruby API, then you can call it as a command from ruby. The latter is not as elegant but works fine. (Be sure to catch and handle errors.)
Digitally signing a pdf is completely different than encryption. The result of signing is a pdf with one or more digital signatures. You use either a library to sign a file locally or, for a more dependable system, sign the file via a dedicated appliance that also holds the signer's private key and certificate.
Unlike password protection/encryption, anyone who receives a digitally signed pdf file can read the file's content. The digital signatures provide the relying party (the recipient) with assurances about:
the identity of the person who signed the file
the integrity of the file (confirming that it wasn't changed since signing)
the non-reputability of the file (confirming that the signer can't claim that they hadn't signed the file)
An important issue is that having a signer's private key on the file system of a regular computer/server is not secure enough to provide any guarantee against repudiation by the signer--she could truthfully say that there is no way to assure that her "signature" was not forged by un-authorized use of the pfx file.
The Origami library has a very basic support for PDF digital signatures and there is sample code for this at https://github.com/gdelugre/origami/blob/master/examples/signature/signature.rb.