Google Storage signed URL: The request signature we calculated does not match the signature you provided - google-cloud-storage

I have a python script that is responsible to sign images url to 150 days (v2) with gcs.
My problem is the url works just fine but after 4 days when I try to enter the image I get
The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method

Related

DocuSign JWT request invalid_grant unsupported_grant_type

I'm working on my first DocuSign web service consumer, in the development environment. At this point, I'm just trying to duplicate the token request procedure on DocuSign's how-to page: https://developers.docusign.com/platform/auth/jwt/jwt-get-token/
I'm sticking as closely as possible to the process shown in their YouTube video. I have created an app with an integration key and an RSA key pair (generated by DocuSign). I obtained application consent as per step 1 of the how-to.
As per step 2 of the how-to page, I entered the following request in jwt.io:
Header: {"typ":"JWT","alg":"RS256"}
Payload: {"iss":"(integration key GUID)","sub":"(API username GUID)","iat":1619972504,"exp":1619975504,"aud":"account-d.docusign.com","scope":"signature"}
I pasted the public and private keys, including the starting and ending strings, into the appropriate fields, and jwt.io created and verified a signature.
As per step 3 and the YouTube video, in Postman, I created a POST request to https://account-d.docusign.com/oauth/token with
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=(encoded token copied from jwt.io)
No matter what I do, the web service always returns
{
"error": "invalid_grant",
"error_description": "unsupported_grant_type"
}
I've spent more time than I care to admit re-reading the how-to page, re-watching the YouTube video therein, and poring over my data for typos, etc.
Ideas, anyone? Thanks!
For part 2 you would also need the scope of "impersonation" for JWT.

How can I make a Google Cloud Storage object publicly visible while uploading it?

I have an application which is uploading objects to Google Cloud Storage using signed URLs and I'd like to know if it's possible to make the object public during the sign/upload step.
I know it's possible to make the object publicly visible by setting the policy on its bucket or by using the client library/making a REST request after it's been uploaded, but in order to minimize the impact on my workflow, I'd like to do it all in one go. Is this possible? If it can be done, I'm assuming it's by setting a header when signing the URL or when making the REST request using the signed URL but I haven't been able to find documentation which covers this.
UPDATE:
I've just found the Extension/Custom Headers section of the XML API docs which claims that this can be achieved using the x-goog-acl header (e.g. x-goog-acl: public-read). Unfortunately, this does not work. The object is not publicly visible after setting the header when signing the URL and when uploading the file.
Quoting the Cloud Storage documenation regarding Signed URLs:
When specifying the name:value pairs for headers, keep in mind the following:
Remove any whitespace around the colon that appears after the header name.
For example, using the custom header x-goog-acl: private without removing the space after the colon returns a 403 Forbidden error, because the request signature you calculate does not match the signature Google calculates.
So the solution could be setting the header value as x-goog-acl:public-read instead of x-goog-acl: public-read.

Google Cloud Storage Signed URL forced response disposition

Got a problem, using GCS signed url feature (https://cloud.google.com/storage/docs/access-control/signed-urls) and want to force response content disposition.
I've used it once before in the past, but now I cannot seem to get it work and cannot find any documentation about Google deprecating this feature.
My current example url: https://storage.googleapis.com/examplebucket/examplefile.pdf?GoogleAccessId=account&Expires=expire&Signature=xx&response-content-disposition=inline
Signing is working and I can reach the file, just cannot force disposition.
If I upload file as Content-Disposition=attachment, then it wont make it inline and vice versa.
Any ideas?
For signed URLs, the contentDisposition metadata property, if specified, overrides the response-content-disposition query parameter. This is because the response-content-disposition query parameter is not part of the signature, which means that end users could change it.
If you want to specify response-content-disposition in the signed URL, clear the contentDisposition metadata property, and the value in the query parameter will be used.

magento REST API not accessible in iphone

When I try to access rest API using iPhone I have passed following parameter in URL and used both methods POST and GET but it displays Access Denied.
oauth_version="1.0",
oauth_signature_method="HMAC-SHA1",
oauth_nonce="B0dlzkfMWCAn0TJ",
oauth_timestamp="1366280813",
oauth_consumer_key="klkjylsiozbv6vfdsqtuheqo3kmqqzv2",
oauth_token="t9pefrwylmg7webyepsqepotlhzbytkp",
oauth_signature="NeOwbCLUPbIyF9ErnHoFQOl9%2Bwo%3D"
I have worked with REST Client plugin available for Firefox and Chrome, REST API is work well using REST Client plugin but not accessible in iPhone.
I am generating a random value for oauth_timestamp, oauth_signature and oauth_nonce then also REST API is displaying Access Denied.
Please provide suggestions.
//here final_sign is signature generated from following procedure.
$nonce = substr(md5(uniqid('nonce_', true)),0,16);
$temprealm="http://magentohost/api/rest/products";
$realm=urlencode($temprealm);
$oauth_version="1.0";
$oauth_signature_method="HMAC-SHA1";
$oauth_consumer_key="dfddfgdgdfgddf6qgygmyvw7e3";
$oauth_access_token="fdgdfgfdgdfg357gimpdnuejvcbtk51ni";
$oauth_method="GET";
$oauth_timestamp=time();
$algo="sha1";
$key="sb88hfdihyg25ipt1by559yzbj2m3861&s7uhaheu8nrx961oxg6uc3os4zgyc2tm"; //consumer secret & token secret //Both are used in generate signature
$data="oauth_consumer_key=".$oauth_consumer_key."&oauth_nonce=".$nonce."&oauth_signature_method=".$oauth_signature_method."&oauth_timestamp=".$oauth_timestamp."&oauth_token=".$oauth_access_token."&oauth_version=".$oauth_version;
$send_data=$oauth_method."&".$realm."&".urlencode($data);
$sign=hash_hmac($algo,$send_data,$key,1); // consumer key and token secrat used here
$fin_sign=base64_encode($sign);
echo $fin_sign;
From your question I understand that you use a random value for the signature and the nonce.
The latter would be fine, but a random signature would lead the receiver not to trust you as a legitimate client.
So, actually, you get the response you requested (;-)). But that does not solve your problem.
You have to generate a valid signature for the magento system.

Trouble authenticating to facebook chat on Blackberry

I am currently working on a blackberry app that needs to connect to facebook chat. I am attempting to use the XMPP/Jabber interface. I can get the challenge from the server, however when I send my response I get a "not authorized" failure. My response is structured in this way:
api_key=[my api key]&call_id=[time in millis]&method=auth.xmpp_login&nonce=[nonce from challenge]&session_key=[explained below]&v=1.0&sig=[calculated as shown below]
For the session key, I send the user a browserfield to Facebook's site. It returns an access token in the form AAA...|BBB...|CCC... where BBB... is the session key
The sig is calculated by taking the following string, md5ing it, and then converting the bytes to a hexadecimal string:
api_key=[my api key]call_id=[time in millis]method=auth.xmpp_loginnonce=[nonce from challenge]session_key=[explained above]v=1.0[secret key appended here]
from there I base64 encode the response, and send:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>[Base64EncodedResponse]</response>
Facebook's response is consistently a not-authorized error, with no adidtional explanation. Is there something that is missing or something? Thanks for the help.
I was able to figure it out. The problem was, it wants the session secret, not the app secret. So the secret key appended at the end of the signature is obtained from calling auth.promoteSession, not from the App Secret on the website.