I am just looking into integration options and have setup a dev account and am working on the basic login_information endpoint. I have followed the documentation and tried using the XML and JSON options when setting the headers.
Both return the same message:
XML:
<errorCode>INVALID_TOKEN_FORMAT</errorCode>
<message>The security token format does not conform to expected schema.</message>
JSON:
{
"errorCode": "INVALID_TOKEN_FORMAT",
"message": "The security token format does not conform to expected schema."
}
I have made another token and tried that, I have also checked that there is no backslash (\) character in my password. I have tried with the API Username and my email address. The Tokens both have 32 characters and 4 (-) and are being submitted as utf8.
The XML GET:
Headers:
BE_HTTP_Set_Custom_Header (
"X-DocuSign-Authentication:" ;
"<DocuSignCredentials>
<IntegratorKey>" & integrator_key & "</IntegratorKey>
<Username>” & username & ”</Username>
<Password>” & password & ”</Password>
</DocuSignCredentials>"
)
Where the quote data e.g. “ & integrator_key & “ is pulling the data from the database.
BE_HTTP_Set_Custom_Header ( "Content-Type" ; "application/xml" )
GET:
BE_GetURL (
"https://demo.docusign.net/restapi/v2/login_information?api_password=true&include_account_id_guid=true&login_settings=all" ; "" )
The JSON GET:
Headers:
BE_HTTP_Set_Custom_Header (
"X-DocuSign-Authentication:" ;
"{
\"Username\":\"” & username & ”\",
\"Password\":\"” & password & ”\",
\"IntegratorKey\":\"" & integrator_key & "\"
}"
)
Where the quoted data e.g. “ & integrator_key & “ is pulling the data from the database, here I need to escape the " of the JSON with the \ e.g. \".
BE_HTTP_Set_Custom_Header ( "Content-Type" ; "application/json" )
GET:
BE_GetURL (
"https://demo.docusign.net/restapi/v2/login_information" ; "" )
The login_information method is used to obtain information about a user only when you're using Legacy Authentication.
You should first decide if you're writing a User App (where the user will be present to authenticate herself) or a Service Integration that will run autonomously in the background.
Then use the appropriate authentication.
A beta recipe that demonstrates both authentication models.
Added
Check that your password doesn't include a reserved XML character that needs to be escaped. < and & need to be replaced with the appropriate entity sequence.
And try authenticating with your email, pw, and integration key via the recipe referenced above. If it works, then the problem is in your code. If it doesn't work then something's wrong with your credentials.
Also, check that when you add an http header that you should include the colon with the header key value.
Related
I want a code to lookup for a username and compare the password ( case sensitive ) using the dlookup
here is my code and it doenst care for the pass if it is capital letter nor not
If (IsNull(DLookup("UserName", "UserID", "UserName='" & Me.Userbox.Value & "'and [password] = '" & Me.Passbox & "'"))) Then
Thanks
I have been testing the musicbrainz API and I found a problem for me. When the title has an '&' in the name the query returns the wrong results.
For example: The title is 'auf & ab' and the query returns a title named 'auf, auf, auf'.
I sort of fixed this by replacing '&' with 'and' like this:
if (title.includes('&')){title = title.replace('&','and')}
This returns the correct results.
I am not sure if this is the way to solve this issue.
This is my query:
https://musicbrainz.org/ws/2/recording/?query=recording:auf%20&%20ab%20%26%26%20artist:montez&fmt=json&limit=5
I think you need to encode the "space" (with %20) and the "&" (with %26) chars, since they are used in url the & will be decoded as another new parameter in query string; try with this:
https://musicbrainz.org/ws/2/recording/?query=recording:auf%20%26%20ab&artist:montez&fmt=json&limit=5
In this way, your search "auf & ab" -> "auf%20%26%20ab"; you can achieve this result using the encodeURIComponent("auf & ab")
Edit: changed encodeURI -> encodeURIComponent
My PayPal IPNs are validating fine, except for those with a txn_type of recurring_payment. When I pass the message to the validation endpoint, I'm converting the body into a query string using
var verificationString = '?cmd=_notify-validate';
Object.keys(body).map((key) => {
verificationString = verificationString + '&' + key + '=' + body[key];
return key;
});
My best guess is that this is messing with the order of the properties. PayPal's documentation states:
Your listener HTTPS POSTs the complete, unaltered message back to PayPal; the message must contain the same fields (in the same order) as the original message and be encoded in the same way as the original message.
But I didn't think Object.keys(body).map would rearrange anything in Nodejs. Any suggestions?
Found the solution. Turns out that PayPal allows user fields to contain things like backslash, newline characters, etc. This specific IPN had an address field with a \r\n newline between the street and apartment number. Using my original code, this was somehow being encoded different.
Instead of assembling the query string like in my original question, I now assemble it like this, since it preserves all characters and encoding:
var verificationString = '?cmd=_notify-validate&' + request.rawBody.toString();
And that solved the problem!
Here is a sample OData URL format used:
https://odata-my-company.net/api/v1/datalake/abcd1234321234ef9887492023/data_tablename/
I have tried using Encoded URL as well substituting ":" as "%3A" and "/" as "%2F"
Also tried removing "https://" altogether.
Also tried using "http://" instead of "https://"
Nothing works.
Any help??? Thanks in advance
=== Error Message Below ===
Connection failed
Failed to create OData connection to RequestUrl
The metadata document could not be read from the message content.
XmlError : '', hexadecimal value 0x1F, is an invalid character. Line 1, position 1. : (1, 1)
Screenshot of same error in Azure Data Factory
Nothing wrong with the url . The error complains about the XML . I know that in ADF we have json all over the place . Just curious if the ODATA is returning XML and you have an issue there . To me it looks like you are looking at the wrong place .
I'm accessing GMail's IMAP interface through python. I run a command like this:
UID SEARCH HEADER Message-ID "abcdef#abc.com"
That succeeds (returns 1 UID of the matching message, or 0 if it doesn't exist). However, if the search-text contains certain chars (like & or !), the search-text is truncated at that point. This means:
UID SEARCH HEADER Message-ID "!abcdef#abc.com"
Is treated the same as
UID SEARCH HEADER Message-ID ""
Also:
UID SEARCH HEADER Message-ID "abc!def#abc.com"
Is treated as:
UID SEARCH HEADER Message-ID "abc"
I've gone through the IMAP language spec, and from the ABNF language spec it seems like those chars should be valid. Why is gmail truncating these search phrases at the "!" and "&" chars? Is there a way to escape them? (I've tried !, fails as a badly-encoded string). Is there an RFC or doc that shows what really should be accepted? Is this a bug in gmail's imap implementation?
I've also tried literal format, same results:
UID SEARCH HEADER Message-ID {15}
abc!def#abc.com
Still treated as:
UID SEARCH HEADER Message-ID {3}
abc
Thanks!
IMAP RFC3501 Search Command: https://www.rfc-editor.org/rfc/rfc3501#section-6.4.4
Formal syntax: https://www.rfc-editor.org/rfc/rfc3501#section-9
I'm largely basing my answer on the discovery (by Max) in the comments to the original question that GMail's SEARCH implementation uses a backing database that has already split textual content into word tokens rather than storing the full text and doing a substring search.
So here's a possible workaround that you could use with GMail in C# using my MailKit library (which is a fairly low-level IMAP library so this should easily translate into basic pseudocode):
// given: text = "abc!abcdef#abc.com"
// split the search text on '!'
var words = text.Split (new char[] { '!' }, StringSplitOptions.RemoveEmptyEntries);
// build a search query...
var query = SearchQuery.HeaderContains ("Message-ID", words[0]);
for (int i = 1; i < words.Count; i++)
query = query.And (SearchQuery.HeaderContains ("Message-ID", words[i]));
// this will result in a query like this:
// HEADER "Message-ID" "abc" HEADER "Message-ID" "abcdef#abc.com"
// Do the UID SEARCH with the constructed query:
// A001 UID SEARCH HEADER "Message-Id" "abc" HEADER "Message-Id" "abcdef#abc.com"
var uids = mailbox.Search (query);
// Now UID FETCH the ENVELOPE (and UID) for each of the potential matches:
// A002 UID FETCH <uids> (UID ENVELOPE)
var messages = mailbox.Fetch (uids, MessageSummaryItems.UniqueId |
MessageSummaryItems.Envelope);
// Now perform a manual comparison of the Message-IDs to get only exact matches...
var matches = new UniqueIdSet (SortOrder.Ascending);
foreach (var message in messages) {
if (message.Envelope.MessageId.Contains (text))
matches.Add (message.UniqueId);
}
// 'matches' now contains only the set of UIDs that exactly match your search query
I've been hitting this issue myself for months now.
SEARCH HEADER Message-ID <-!&!...>
Ended up skipping some MsgId searches that start with '<-'. Also see the problems with &!'s ... Not sure how to workaround this well.
Have you ever got a word from Google on this bug?
Thanks much