The context :
- I want to send request to the service layer of a Hana data base
- I use the Webhook from Zappier to sent POST or GET method (I suppose this is the good component ?)
- I use classic GET or Custom Request with the Webhook from Zapier
My problem :
- it seems that if the URL contains a space character, it doesn't work properly :(
example :
https://<<the_beginning_of_the_url>>/PurchaseOrders?$select=DocEntry,DocNum,CardCode,CardName&$orderby=CardName => WORK FINE(NO SPACE)
https://<<the_beginning_of_the_url>>/PurchaseOrders(30)?$select=DocEntry,DocNum,CardCode,CardName&$orderby=CardName => WORK FINE(NO SPACE)
https://<<the_beginning_of_the_url>>/PurchaseOrders?$select=DocEntry,DocNum,CardCode,CardName&$orderby=CardName desc => **DOESN'T WORK** (SPACE BEFORE 'desc')
https://<<the_beginning_of_the_url>>/PurchaseOrders?$select=DocEntry,DocNum,CardCode,CardName&$orderby=CardName%20desc => **DOESN'T WORK** (SPACE BEFORE 'desc')
https://<<the_beginning_of_the_url>>/PurchaseOrders?$select=DocEntry,DocNum,CardCode,CardName&$orderby=CardName+desc => **DOESN'T WORK** (SPACE BEFORE 'desc')
All this (except the last with '+') work fine with Postman
I've tried to use Formatter by Zappier and Text/URL Encode method before sending the URL, but it doesn't work
Any idea ?
It's seems that Webhook By Zapier encode the URL before to send it.
So the true URL which is send contains '+' even if we submit a space or %20
Is it possible not to encode URL before Webhook send it ?
We really need to send a URL with %20 or space
Related
I'm parsing the slack message log from conversations.history and any app mentions come in as <#XX12345>. I'm trying to parse the XX12345 part in a conversation and replace it with username and get rid of the < and >. For eg:
Hello <#UA12345> how are you?
I'm good <#UA67890>. How about you?
should become
Hello #lookup(UA12345) how are you?
I'm good #lookup(UA67890). How about you?
How do I achieve this using replace and regex in DataWeave? The lookup function is used to get the user name from Slack API. This function also needs to be triggered inside Dataweave (not sure if this is even possible). End result would be something like this:
Hello #Adam how are you?
I'm good #David. How about you?
Assuming the username in <#UA67890> is alphanumeric, you can use the following expression to get the required result
yourText replace /\<\#([a-zA-Z0-9]*)\>/ with "#$(getUsername($[1]))"
This matches the regex \<\#([a-zA-Z0-9]*)\> which captures alphanumeric value in between a <# and > in a group and then replace it with #$(getUsername($[1])), i.e. #getUsername(everything that was captured as in the above group)
You can create the function getUsername to actually call the lookup function and call the required flow. So your DataWeave will look something like this.
%dw 2.0
output text/plain
fun getUsername(userid) = lookup('get-user-name-flowname', userid) // Any other transformation that you may need for passing the required payload before calling loopup
var conversation =
"Hello <#UA12345> how are you?
I'm good <#UA67890>. How about you?"
---
conversation replace /\<\#([a-zA-Z0-9]*)\>/ with "#$(getUsername($[1]))"
Update: As mentioned in comment, you also need a flow get-user-name-flowname that will either use slack's REST API or <slack:get-usersprofileget> which will accept this ID and will return the username of the user
I am using standard Telegram Bot API for sending messages. When a photo url contains a special character like a right single quotation mark (’) and left single quote (‘), the message is not sent, as it is a Bad Request.
When php rawurlencode is run, ’ shows as %E2%80%99 and ‘ as %E2%80%98
$photourl='https://example.com/some/path/name-of-image-with‘quotes’.jpg';
$array =[
'chat_id' => $uid,
'photo' => $photourl,
'caption' => $caption
];
file_get_contents("https://api.telegram.org/bot$api/sendPhoto?".http_build_query($array) );
it gives a
PHP WARNING --
failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request
Try this:
$photourl = 'https://example.com/some/path/name-of-image-with‘quotes’.jpg';
$filename = basename($photourl);
$photourl = str_replace($filename, urlencode($filename), $photourl); //Replace file name wirth url encoded filename
$array = [
'chat_id' => $uid,
'photo' => $photourl,
'caption' => $caption
];
file_get_contents("https://api.telegram.org/bot$api/sendPhoto?" . http_build_query($array));
Using characters like ’,‘ or * in photo parameter seem to cause a problem.
I don't have any explanation why this error occurs or how this fixes it. But you can url encode the URL's file name part before passing your query to http_build_query(), (which will encode it even a second time).
In our application we make calls to the Microsoft Graph API to fetch the email header data.
During the initial call to the api we received the following conversationId details for an email
{"conversationId":"AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk+h7byQ="}
And a few seconds later when we made a similar request for the same email, we received a different conversationId
{"conversationId":"AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk_h7byQ="}
Now the expectation here is that the value of the conversationId should always remain the same.
In the above scenario the only difference in the 2 conversationId returned is the '+' being replaced with the '_'
AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk+h7byQ=
AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk_h7byQ=
Detailed Steps:-
The owa mail dom is parsed to fetch the conversationId
AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk+h7byQ=
Using this conversationId we make a call to the MS Graph API and get the details including the messageId which we store in our DB as a primary key
A few minutes later, we make another MS Graph API call, this time using the messageId, and in response we get a different conversationId
AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk_h7byQ=
Question:-
Is it possible by any chance that + and _ are interchangable
You shouldn't assume Exchange identifiers are interchangeable across platforms. Over the years, Exchange has used a crazy number of different formats for identifiers. This is likely the crux of the issue here.
There are some mechanisms for converting between them but I generally advise against it unless you've got no other option.
I'm not sure why/how you're parsing the OWS DOM but I'm frankly more surprised the identifiers are that close than I am that it doesn't work as expected. If you want to pull the message from Graph from within OWA, I would use an Outlook Web Add-in for this. The add-in framework includes a convertToRestId method that returns an identifier you can use with Microsoft Graph:
function getItemRestId() {
if (Office.context.mailbox.diagnostics.hostName === 'OutlookIOS') {
// itemId is already REST-formatted
return Office.context.mailbox.item.itemId;
} else {
// Convert to an item ID for API v2.0
return Office.context.mailbox.convertToRestId(
Office.context.mailbox.item.itemId,
Office.MailboxEnums.RestVersion.v2_0
);
}
}
As for the + vs _, this comes down to the encoding format. There are multiple flavors of Base64. Standard In standard Base64, the 62nd character is + and the 63rd is /. This presents a problem when you want to use Base64 in a URL as + and / are reserved characters. To get around this, you need a URL safe variant of Base64. There are several such variants out there. The most common is base64url (defined in RFC 4648) which swaps out the - for the 62nd and _ for the 63rd.
I have a website using angular.js and my backend is using asp.net web api. When a new user register a e-mail is send with an activation link and a token inside it like this :
localhost:51426/#/activation?userid=test&code=FCuuf27NzVvmwp2Ksd7IDt83C2XZmZ2paCrZPBLgr9qR8xCaXELvqKCsWlg4uiokb07XK5sQ+2BazHN1+2B74q14grkQY2OHDAVeWlin5GE8ugkyw+2BJFFzd3Q2YiVuMxkmkO6OFdhIyfzUQMV8NPipME+2FST1pa0OuQs90kRUNR5kTkPlGQYKflDOMQvDGV84fZIw
When the user click the link I have an angular controller that basically just take the parameter and call the good method inside the web.api like this :
return $http.post(baseUrl + 'api/v1/account/confirmAccount?userId=' + userId + '&code=' + code);
The problem it seems all the + are replace by space in the server side so when I try to validate the token in my web api it doesn't work.
Not sure to understand why the + it's replace by space and how to avoid this.
Thanks
The problem is that in query strings + characters are replaced by spaces:
URL Encoding:
The HTML specifies the following transformation:
SPACE is encoded as '+' or "%20" [9]
What you could do is replace the space characters with + on the server:
string newCode=code.Replace(' ','+')
One option might be to build the string first and eliminate the + altogether.
When I receive a notification from Paypal, I send it back to Paypal to be sure it is from Paypal.
The code works well and I have no problem:
# payment_notifications_controller.rb # notification_validation, line 90
response = RestClient.post(PAYPAL_CONFIG["url_validate"], params.merge({"cmd" => "_notify-validate"}), :content_type => "application/x-www-form-urlencoded")
The problem is when the user has a Japanese name. The notification (from Paypal) received is like:
Parameters: {"last_name"=>"\x8F\xBC\x8C\xB4", "payment_cycle"=>"Daily", "next_payment_date"....
When I'm trying send it back to Paypal (to be sure it came from Paypal), I have this error:
ArgumentError (invalid byte sequence in UTF-8):
app/controllers/payment_notifications_controller.rb:90::in `notification_validation'
It's like if RestClient doesn't like "\x8F\xBC\x8C\xB4".
I tried to add :content_type => "shift_jis" and also "utf-8", but I always have this error.
If I do something like:
params[:last_name] = params[:last_name].encode("UTF-8", "Shift_JIS")
# now params[:last_name] is 松原
Then my RestClient.post is send to Paypal, but Paypal return an error (INVALID) probably because Paypal was waiting to get "\x8F\xBC\x8C\xB4" and not "松原".
Do you have any idea of how I can resolve that ?
edit:
I also post on paypal forum
So I think I have the solution.
In the seller paypal account go to :
Profile > My selling tools > PayPal button language encoding > More options
Use the following drop-down menu to select the encoding used on your
website.
Encoding: Shift_JIS
Do you want to use the same encoding for data sent from PayPal to you
(e.g., IPN, downloadable logs, emails)?
NO, use:
UTF-8
Now I'm able to get "VERIFIED".