According to Google's Official Documentation on the Email Settings Signature API
https://developers.google.com/admin-sdk/email-settings/#updating_a_signature
I was trying to set the signature value to be html but was getting an error saying that I can't include < (which is from the ).
Any work around?
The error message is
The value of attribute "value" associated with an element type "null" must not contain the '<' character. 0
Related
I'm using the FB Graph API explorer and version 11.0 I've added the page id, feed and fields. Previously we were using 'link' and 'title' but according to the docs here those are deprecated and these are the new field names:
attachments{unshimmed_url}
attachments{title}
but when I add this to the FB Graph API Explorer I either get the error:
Field attachments specified more than once. This is only possible
before version 2.1
or I only get the first mentioned attachments field (attachments{unshimmed_url})
1234567/feed?fields=attachments{unshimmed_url}&attachments{title}
Can’t reproduce this error right now, using v11.0, but it should work if you just list the sub-fields comma separated:
…/feed?fields=attachments{unshimmed_url,title}
https://developers.facebook.com/docs/graph-api/advanced#fieldexpansion
Edit: Can reproduce, with the “correct” incorrect syntax.
feed?fields=attachments{unshimmed_url},attachments{title} throws this error; you had feed?fields=attachments{unshimmed_url}&attachments{title} in your post, which is a different thing - that’s one URL parameter named fields, and then one named attachments{title}
I am seeing this error when I try to hit endpoint using postman:
{
"errors": [
"token contains an invalid number of segments"
]
}
Console:
TypeError: Cannot read property 'jwt' of undefined
The question is a bit vague, but in this case - TypeError: Cannot read property 'jwt' of undefined.
The object that should have the property jwt, is undefined. So the token itself doesn't exist, and neither does the object that is supposed to hold it.
More generally, this error may occur if the token is malformed.
It should have 3 segments, like this [separated by . ]-
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Each of those segments can be decoded by base64 to inspect the header, payload, and signature.
Which results in this -
from - https://jwt.io/
More information from https://www.ibm.com/docs/en/cics-ts/6.1_beta?topic=cics-json-web-token-jwt
Header
The header typically consists of two parts: the type of the token, which is JWT, and the algorithm that is used, such as HMAC SHA256 or RSA SHA256. It is Base64Url encoded to form the first part of the JWT.
Payload
The payload contains the claims. There is a set of registered claims, for example: iss (issuer), exp (expiration time), sub (subject), and aud (audience). These claims are not mandatory but recommended to provide a set of useful, interoperable claims. The payload can also include extra attributes that define custom claims, such as employee role. Typically, the subject claim is used to create the OpenID Connect user subject. However, the Liberty JVM server can be configured to use an alternative claim. The payload is Base64Url encoded to form the second part of the JWT.
Signature
To create the signature part, the encoded header and encoded payload are signed by using the signature algorithm from the header. The signature is used to verify that the issuer of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
More information about the spec here -
https://datatracker.ietf.org/doc/html/rfc7519#page-7
The project uses a swagger.
There is the following code.
#swagger_auto_schema(
manual_parameters=[
Parameter('download', IN_QUERY,
'Set `Content-Disposition=attachment` to make browser to download file'
'instead of showing it.',
type='bool'),
Parameter('share_id', IN_PATH, type='uuid')
],
security=[],
responses={'400': 'Validation Error (e.g. base64 is wrong)',
'200': VideoSerializer}
)
Please explain what each argument is responsible for.
I read the documentation, but understood little ...
Particularly interested in '200': VideoSerializer
responses
The responses argument is a dictionary of possible responses that this endpoint can return.
400 and 200 are HTTP response codes, Bad Request and OK respectively.
In this case, this means that this endpoint can generate two types of responses:
Bad request which will also return (as described) a Validation Error which means that something in the request was incorrect, which means it could not be handled correctly.
OK, which means the request is correct, and everything was handled correctly. VideoSerializer means that a response will be given with accordance to the structure of the VideoSerializer, which defines a collection of fields.
The other two arguments:
manual_parameters
This a custom list of parameters that can be added to the request to customize the response.
In this case, two parameters are defined:
download : A query parameter of type bool. Query parameters are passed like this : `example.com?query_parameter=true
share_id, a path parameter of type 'uuid'. Path parameters are passed like this : example.com/path_parameter
security
A list of security schemes that the request must adhere to. Used for instance for Basic authentication.
I'm developing an Android App that uses the Places API to retrieve information and displays it on a map. The initial request to retrieve to places fails with a ACCESS_DENIED status message from the HTTP request. Below is the code that I used to generate the request:
try {
HttpRequestFactory httpRequestFactory = createRequestFactory(HTTP_TRANSPORT);
HttpRequest request = httpRequestFactory
.buildGetRequest(new GenericUrl(PLACES_SEARCH_URL));
request.getUrl().put("key", API_KEY);
request.getUrl().put("location", _latitude + "," + _longitude);
request.getUrl().put("radius", _radius); // in meters
request.getUrl().put("sensor", "false");
if(types != null)
request.getUrl().put("types", types);
PlacesList list = request.execute().parseAs(PlacesList.class);
// Check log cat for places response status
Log.d("Places Status", "" + list.status);
return list;
In another Stackoverflow posting someone had suggested that the poster try the following to test their key:
Go to the api console here, then to SERVICES. Click Active services
tab and verify 'Places API' is turned ON. Click on the ? "try" link
next to it. It should create a proper URL with your key which should
work. Compare the link that you are trying against this URL for
differences.
I followed these instructions. Based on the fact that I received the following results when I clicked on the ? to "try" the link I suspect something is fundamentally wrong with the API Key independent of the code...otherwise I would think I would get a SUCCESS rather than REQUEST_DENIED:
{
"html_attributions" : [],
"results" : [],
"status" : "REQUEST_DENIED"
}
I obtained my key by entering the SHA1 of my debug certificate (which i obtained using Keytool with all the appropriate parameters...e.g, androiddebugkey....debug.keystore) followed by a ";" and the Package Name of the app.
Not sure what the problem is...I'm sure it's something simple but I'm not seeing it and I'm stuck. Thoughts?
I never received a response to this posting so ultimately I've resolved the problem by creating a brand new key under a new project name and I was at least able to retrieve Places from Google..I'm still having issues with populating maps but that could be a code issue.
I noticed that the key that I was using that gave me the ACCESS DENIED results had a title of: "Key for Android apps (with certificates)" and it had a label "Android apps:" listed just under the actual key. The key value is the SHA1 value ";" followed by the Package Name. Whereas the key I created under a new Project Name (Places API) that ultimately worked had a title of: "Key for browser apps (with referers)" and it had a label of "Referers:" and value of "Any referer allowed".
So there is definitely something different about these two keys. I'm not sure what I did differently when I generated the keys. I'd like to understand what I did to generate these two "different" types of keys so that I and perhaps others won't repeat my "mistake(s)".
There are many references to creating keys in the Google documentation. The fact that there are so many postings regarding problems with the keys tells me that the Google documentation is not very clear otherwise so many issues wouldn't exist on this topic.
I'm going to write a program can post and read messages from SQS with authentication and I've read the document from here
Link: Query Request Authentication
I have successfully written the process which post a message to specified queue follow by the document. But I always get 403 error when I try to receive message from queue. And I found the signature string rules are different for POST and GET methods.
the signature string is:
GET\n
sqs.us-east-1.amazonaws.com\n
/<My Account Id>/<Queue Name>\n
AWSAccessKeyId=<My Access Key>
&Action=ReceiveMessage
&MaxNumberOfMessages=10
&VisibilityTimeout=600
&AttributeName=All
&Expires=2012-04-01T11%3A29%3A24Z
&SignatureMethod=HmacSHA1
&SignatureVersion=2
&Version=2011-10-01
and the url is
https://sqs.us-east-1.amazonaws.com/<My Account Id>/<Queue Name>?
Action=ReceiveMessage
&MaxNumberOfMessages=10
&VisibilityTimeout=600&AttributeName=All
&Version=2011-10-01
&Expires=2012-04-01T11%3A29%3A24Z
&Signature=<BASE64 encoded HmacSHA1 digist with signature string and my security key>
&SignatureVersion=2
&SignatureMethod=HmacSHA1
&AWSAccessKeyId=<My Access Key>
And I always get the 403 forbidden error:
<ErrorResponse xmlns="http://queue.amazonaws.com/doc/2011-10-01/">
<Error>
<Type>Sender</Type>
<Code>SignatureDoesNotMatch</Code>
<Message>
The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
</Message>
<Detail/>
</Error>
<RequestId>16f6e910-62e6-4259-8c09-0358b84cbe60</RequestId>
</ErrorResponse>
Is there anyone can tell me how can I deal with it? Thanks a lot
The error message tells you that the signature is being calculated wrong. This is really tough to debug. I spent hours on it the first time I tried it. There's an example signed SQS request at http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/MakingRequests_MakingQueryRequestsArticle.html. You should put those parameters in your program, calculate the signature, and try finding bugs into your program creates the same signature.
Specific problems I had, and fixes for them included:
Sorting the query parameters correctly. They must be in ascending order when creating the string to sign. Your example URL does not show them in order. Did you sort them differently when creating the string to sign?
URI encoding properly. Every parameter must be URI encoded in the string to sign. Your sample URL does have URI encoding, so this probably isn't your issue. But make sure you're not double-encoding.
Padding the base64 signature. At least some AWS services insist that the signature be a multiple of four characters long. Two-thirds of the time a base64 encoding will be too short, and need one or two equal signs appended to it. Most base64 encoding libraries do that for you, but not all.
Of course, the easiest thing is to use somebody else's library to make the requests, but what's the fun in that? Good luck debugging this.
It's most likely the parameter order: when assembling the signature version 2 string, at the last step the Amazon documentation specifies:
Add the query string components (the name-value pairs, not including
the initial question mark (?) as UTF-8 characters which are URL
encoded per RFC 3986 (hexadecimal characters must be uppercased) and
sorted using lexicographic byte ordering. Lexicographic byte ordering
is case sensitive.
I've spent two days debugging this same "SignatureDoesNotMatch" issue by checking my HMAC, BASE64 and URL encoding procedures and it was just a problem of parameter order.
The documentation should emphasize this issue more; if you use unordered parameter strings (e.g. the same one in the request URL, like those found in the documentation examples), you're going to get this non-intuitive error from the server.