Go to this page:
https://products.office.com/en-us/office-online/view-office-documents-online
If you paste a url of an office document(e.g. http://ieee802.org:80/secmail/docIZSEwEqHFr.doc) to the input box and click "create url", it will generate a url which allows you to view the file in browser.
However this doesn't work for a signed url:
https://test-sam-sydney.s3.amazonaws.com/561/smartlibs/141/entries/16288/files/32683/aaa.doc?AWSAccessKeyId=ASIAI37CPWZSXOXMYGWA&Expires=1509595541&Signature=czEeo7dko8%2Fj96AYX9HTK5dV8IU%3D&x-amz-security-token=FQoDYXdzEP3%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDJ%2FRBcrYuZWaVCkhTSKoBvKIryDttKvnIMTdcNvRwlURajDqOsmDn2AGGWfuh%2BfXAZ9HkMHbP7boPcPaz2n1YG0HibDeuVp1haOBqxjylleC0XtSCIYF6zOGGP9TYAoncUx29z3NDL4tVdfkvxus8kV8sCuMPleiocAkIYeWnfTAGIc%2B7bDzx4DlkOaBtmYpY5XFWGJTGhS7kN%2Bv8qYE53gbWI0yv6w7SDC8bREW8EgH0Nt4Zi5i87psPgjAqmW9JypIcUdIKY%2FhZ7%2BE9Cmpvvqwt2t8aYFAT2X5FVgTQbImFcJrRTjx3kDNJgrI6TVpoC1kKt%2B15EBjYYWP9XECfFGeID%2F3MqluU4XBagHZ45vI5phska6nLyyWHq0%2FgGK06lLW%2BPJpCl%2Bg2u2XEy%2B%2FaqoNhoWNKeo7YQ9IP9LS2rkqZJ5Wm4RzD6VDV0waUDOOCR0iwQl9C8bkhFLxi6cYv6MViO5EYxZygaxmtKh%2FVC1BcoRL4XRq6WP%2BHIQiVaA67PXfyMspoGk3Wn31zwhAGsRRi2%2Fh5kEiJ7wXw%2FYCppokL7VBogEDIyuv5HgXtOLsPvMsEdbwEvNNLYYvTMmby911%2FChbzLVgn7I4ui1C5eqwJosZWyjwbQWrwzvNPYi9xqty%2B9Fja3YlmMUUjBe5eDkKzPEUDGZ28beckUU%2FhDptseaZDehmmsODwQd5AFmJ0MUdXH6E333N3rgLo%2BvmSptLrRcd%2BIfpiV8cNdMyXsK3k2%2FSblpRA5rMsP4gbMiveXMmHGtcsonjMipuyjWReWb5z5S%2BcIeeZLjOVBDtqyYdixDsqj62q9K5qGRPiKBeWHO6IP9IzqM4EY8GfKpVy2GEE30tdx9MB94pQmQSMNEUigREYuELKvrS4kbUXiTNZ635pqxEDeBq%2FHP3iOlodbvqIEFeS0iG2X46Sc%2FZ1sixPW1umvNkNJCABjHcPvupIWwzqdiA6N6V%2FTb%2FVZHbBBHqkv4quBn8xGm3LORiuEsXRoRTVMeor2sdOu6nhJuAHz9IpdPvnqQ4mExsBWOY4lMD5sOZ1PoGuDThbcDFc4LfBK96jRC8KCF%2BEiP1FUjVhtw4nkMhpq0ojazqzwU%3D
It expires after 15min so by the time anyone sees this it must have been expired, but I guarantee it is a valid url and if you paste that in browser it will download that doc.
This was working about 2 months ago, but not working now, I wonder if Microsoft has changed something, does anyone know the reason?
I was having the same issue. Eventually, I found out that the URL was not being encoded. The signed url introduces characters to the URL that must be "escaped" or encoded for the Microsoft Office Viewer to be able to read them. See this other question for more information.
I had to encode it with encodeURIComponent()
Note that encodeURI() will not fix the issue. It does not encode as many characters that encodeURIComponent does.
Related
I am trying to create a Power Automate flow that automatically syncs to Dropbox a file contained at a URL link in emails.
The email is always from the same email address, let's say: "example#example.com"
The URL link always has the same hyperlinked text: "Link to Signed Affidavit with Original Document Attached"
The URL link itself is dynamic and looks something like this (example): http://www.example.net/asp/showattachment.aspx?BlobID=aso23-gjin42-skgn34-23632
Each such email only contains one such link.
When the link is clicked, it goes to a PDF file in the webrowser. The link is not redirected to a different link.
I'd like this to trigger every time such an email is received. I'd like this to operate in the cloud without any desktop interaction.
Thanks!
I solved this myself.
In the "Compose" section, you need to parse out the URL from the email body using your own code. Below is what I used for my specific usage case. For my specific situation, I knew the URL would always be the same number of characters. If the URL length varies between emails, you'll need a more complex parse.
substring(outputs('Html_to_text')?['body'],add(58,indexof(outputs('Html_to_text')?['body'],'Link to Signed Affidavit')),95)
I have a Zapier zap that takes an Outlook email from a folder, and appends a text entry in an inbox.txt file in my Dropbox, which I then convert to inbox.org. The text entry has the email subject as the TODO headline, and the note has the Outlook email URL from Zapier plus a body preview.
When I click on the URL link in org-mode, it does not work. For some reason, org-mode is screwing up the URL when it passes it my Chrome browser (I am on a Mac, using the latest Emacs for Mac version).
Here is an example. The "GOOD" URL is what is actually in the inbox.org file as seen in Emacs. If I manually copy and paste that URL into Chrome, no problem. But, if I simply click on the URL in Emacs, the "BAD" URL is what appears in the browser. Notice how some characters are different.
Anyone have clue? . I also use Beorg on iOS, and it correctly opens the link on my iPhone.
GOOD
https://outlook.office365.com/owa/?ItemID=AAMkADI2ZGEzMWMzLTVkOTItNGRkOS04ZjkzLTVmODUzNDZhMjE3OABGAAAAAACfpz95dsWeQ5i6qmcPiDh6BwC6Rj4Y9RfWRZ26IgJTOwZ1AAMJ4B%2BqAAC6Rj4Y9RfWRZ26IgJTOwZ1AAMUEGjBAAA%3D&exvsurl=1&viewmodel=ReadMessageItem
BAD
https://outlook.office365.com/owa/?ItemID=AAMkADI2ZGEzMWMzLTVkOTItNGRkOS04ZjkzLTVmODUzNDZhMjE3OABGAAAAAACfpz95dsWeQ5i6qmcPiDh6BwC6Rj4Y9RfWRZ26IgJTOwZ1AAMJ4B+qAAC6Rj4Y9RfWRZ26IgJTOwZ1AAMUEGjBAAA%3d&viewmodel=ReadMessageItem&exvsurl=1&path=
I assume this has nothing to do with Orgmode itself, but how your browser interprets the url you hand over from emacs. The "plus" sign is not encoded (%2B) and therefore your Browser does not just leave the "plus" sign in the url but interprets it and normally turns it into a space.
Trying to retrieve general page info using the Facebook graph API using an Jquery/Ajax call. This works flawlessly until I request a page containing special characters or dashes in it's name.
It seems like the special characters are ANSI encoded during the ajax request so the name is malformed and the page cannot be found. I can't find a way though to obviate this.
Example url: https://graph.facebook.com/Musée-de-la-Photographie-Charleroi?access_token=[my_access_token]
Can anybody help me out?
I think you should test different values in contentType parameter. It allows to set char encoding.
Take a look here:
http://api.jquery.com/jQuery.ajax/
It seems like the special characters are ANSI encoded during the ajax request so the name is malformed and the page cannot be found.
No, I don’t think that’s the problem.
As you can see from https://developers.facebook.com/tools/explorer?method=GET&path=18521449287, this page does not have a username set yet – and since it is not accessible via just www.facebook.com/Musée-de-la-Photographie-Charleroi, but only via www.facebook.com/pages/Musée-de-la-Photographie-Charleroi/18521449287 including the page id.
And accordingly, info about the page on the Graph API is only available via the page id as well.
Try using the page_id instead (in this case 131141113604635).
https://graph.facebook.com/131141113604635?access_token=[my_access_token]
You may get this id by opening the page on the browser and pressing Ctrl+U, Ctrl+F and searching for a 'page_id' value.
We have an arabic website and we are trying to share a Url on face book. The Url looks like
http://www.website.com/ar/شاهدى-عروض-الأزياء-العالمية-بعيون-عربية/موضة/story/75
The problem is that the facebook does not get thumbnails present on the above link.
When we debugged this through fiddler, we found that the url that facebook is trying to access is not the same as given above, this url is like
www.website.com/ar/%c3%98%c2%b4%c3%98%c2%a7%c3%99%e2%80%a1%c3%98%c2%af%c3%99%e2%80%b0-%c3%98%c2%b9%c3%98%c2%b1%c3%99%cb%86%c3%98%c2%b6-%c3%98%c2%a7%c3%99%e2%80%9e%c3%98%c2%a3%c3%98%c2%b2%c3%99%c5%a0%c3%98%c2%a7%c3%98%c2%a1-%c3%98%c2%a7%c3%99%e2%80%9e%c3%98%c2%b9%c3%98%c2%a7%c3%99%e2%80%9e%c3%99%e2%80%a6%c3%99%c5%a0%c3%98%c2%a9-%c3%98%c2%a8%c3%98%c2%b9%c3%99%c5%a0%c3%99%cb%86%c3%99%e2%80%a0-%c3%98%c2%b9%c3%98%c2%b1%c3%98%c2%a8%c3%99%c5%a0%c3%98%c2%a9/%c3%99%e2%80%a6%c3%99%cb%86%c3%98%c2%b6%c3%98%c2%a9/story/75
I need to know what facebook did to the url that it became as shown.
One more thing that i know is that this url is not UTF8 encoded. If the given arabic url is converted to UTF8 then it looks like following and not as above
www.website.com/ar/%D8%B4%D8%A7%D9%87%D8%AF%D9%89-%D8%B9%D8%B1%D9%88%D8%B6-%D8%A7%D9%84%D8%A3%D8%B2%D9%8A%D8%A7%D8%A1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%85%D9%8A%D8%A9-%D8%A8%D8%B9%D9%8A%D9%88%D9%86-%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9/%D9%85%D9%88%D8%B6%D8%A9/story/75
So i need to know which encoding the face book is using or what facebook is doing to access the following url when we share the url
www.website.com/ar/شاهدى-عروض-الأزياء-العالمية-بعيون-عربية/موضة/story/75
http://www.website.com/ar/شاهدى-عروض-الأزياء-العالمية-بعيون-عربية/موضة/story/75
That's not a URI (or URL). It's an IRI. Unfortunately a lot of software doesn't support IRI directly (including SO, as you can see from the way it has linked only the first part of the address!).
So if you want the link to work everywhere you'll have to write it up as a plain URI with UTF-8-URL-encoded pathnames, as in the last example (%D8%B4...). Browser will usually present the encoded link in the address bar as a nice IRI regardless of the link in the HTML document being plain URI.
%c3%98%c2%b4... is what you get when you take bytes that are UTF-8 encoded and treat them as if they were ISO-8859-1-encoded (and then UTF-8-URL-encoding them again, giving a broken “double UTF-8”). How are you getting the IRI into Facebook? Either there's an interface you're using that you're sending UTF-8 but which expects ISO-8859-1, or it's just a plain old bug on Facebook's part. Either way, you'll have to use the URI version for now.
I have an MS-Word document with a hyperlink. The hyperlink points at an authentication redirector on my server. When I control-click on the hyperlink, my server logs report that it
does a fetch with IE, then
fetches the redirect url with IE, then
launches the "default browser", which is Firefox in my case, and re-fetches the second (redirect) URL.
What gives? Is this by design?
I noticed this because my auth system is currently dependent on cookies set by the redirector. I have some ideas about using url-based auth for this bit, but I need to know what is motivating Word's behavior first.
I have some guesses but I'm looking for something authoritative (or at least a better-informed guess).
Unfortunately, yes. And they try to blame it on "a limitation of the single sign-on system used by the web server"...
http://support.microsoft.com/kb/899927
Actually, this is a "feature". If the hyperlink is to a Word document, word will attempt to download the document and open it. (You must be thinking it's IE because of the user-agent, but the request is coming from WinInet in the the Word process.)
The mess comes about when the server doesn't respond with a page, but rather responds with a redirect and cookies. Word follows the redirect to see if it's going to get a Word document, and it eventally ends up with an HTML page. It then decides that Firefox should display it, so it launches Firefox with the final redirected URL, (but without any of the cookies that the server sent).
Firefox may end up needing those cookies, if this is an SSO sign-on.
Late addition:
Noticed the same problem. Here with MVC 4 it caused the loss of querystring information.
Word launches the browser only after it receives a Http 200 status.
So I avoided this by checking in the controller whether the request comes from IE7 (representing likely only to be MS Word) and returning a 200 manually.
Then the 'real' browser will re-send the http request and all's well ends well, since from there the request is processed normally and all information is retained in the session with the 'real' browser.
Bit of a workaround, but hey, it works. And it's only for a small amount of requests (in our case).