I would like to programmatically retrieve thumbnails of documents from SharePoint. What I'm trying to do is the following:
document.GetImagePreviewUrl(width, height, clientType);
This just returns an empty ClientResult. I am not sure what to enter as clientType value.
I have also tried to use this method programmatically (by using WebClient and downloading the file). But that just returns a 403 response.
The possible solutions I see here are the following:
Figure out what to enter as clientType and retrieve the preview url that way.
Figure out how to tell SharePoint that I am authorized programmatically (using WebClient and headers for instance).
I do need some help regarding these two options, I am not sure where to start since both options aren't well documented.
I've figured out a way to do it, the 403 error was caused because sharepoint had no idea who I was. After some research and fiddling I found out that the request you send to the preview page contains an authentication cookie. This cookie can be generated by code using this piece of code:
// Create an authentication cookie which we can send with the request so sharepoint knows who we are.
var authCookie = credentials.GetAuthenticationCookie(new Uri(imageUrl));
client.Headers.Add(HttpRequestHeader.Cookie, authCookie);
// Download the image data to a byte array
image = client.DownloadData(imageUrl);
Related
This C# code, with a proper access token (for scope drive.readonly) in the Authorization header, will work fine and return the file metadata in json format
_httpClient.GetAsync($"https://content.googleapis.com/drive/v3/files/{someDriveFileId}")
However this code (still with the same access token) will return a 403 :
_httpClient.GetAsync($"https://content.googleapis.com/drive/v3/files/{someDriveFileId}?alt=media")
And the following response html (exactly as returned) :
<html><title>Error 403 (Forbidden)!!1</title><a
href=//www.google.com/><span id=logo
aria-label=Google></span></a><p><b>403 Forbidden</b><p>Your client
does not have permission.\n
I've been using this code in production for years and it worked fine, so i suppose it's related to the recent changes at Google regarding the OAuth screens ?
I'm not sure what i should change here, or what i'm doing (now) wrong. Also the message seems a little sketchy for something made at Google, makes me think there is maybe an issue on their side ?
UPDATE:
Thanks to #Iamblichus for fixing the layout of my original answer. I'm newer to stackoverflow posting.
Even though the change in the original answer appears to be at the root of the problem, I found it difficult to use the troubleshooting steps to come to a working solution. I also was already passing the Authorization Bearer token solution, and that was not fixing my problem. After some trial and error the change I had to make was:
Broken GET URL:
https://content.googleapis.com/drive/v2/files/MY_FILE_ID?key=MY_KEY&alt=media&source=downloadUrl
Working GET URL:
https://www.googleapis.com/drive/v2/files/MY_FILE_ID?alt=media&source=downloadUrl
NOTE:
I am using v2 of the API, so you would need to update to url to v3 if using that.
In the file object I get from the google filepicker v2 API, I don't get back a single URL that supports the change made in authentication. I had to concat the file.selfLink string to make the new URL work
var url = file.selfLink + "?alt=media&source=downloadUrl";
ORIGINAL ANSWER:
Is it possible that https://cloud.google.com/blog/products/application-development/upcoming-changes-to-the-google-drive-api-and-google-picker-api is your problem?:
download calls to files.get, revisions.get and files.export endpoints which authenticate using the access token in the query parameter will no longer be supported.
Only requests that download media content (alt=media) are affected by this change.
The access token should be provided in the HTTP header, like Authorization: Bearer oauth2-token or, if that's not possible, follow the workarounds provided in the referenced documentation:
For file downloads, redirect to the webContentLink which will instruct the browser to download the content. If the application wants to display the file to the user, they can simply redirect to the alternateLink in v2 or webViewLink in v3.
For file exports, redirect to the export link in exportLinks with the desired mime type which will instruct the browser to download the content.
Reference:
Changes in authorization to Google Drive API
Authorization via HTTP header
v2 files get documentation
v3 files get documentation
Implementing a code of Embedded Signing in MVC C# Project. When I post for the sign document, It's redirecting to DocuSign page and it will redirect to return URL. using below code
private const string returnUrl = "http://localhost:5050/DSReturn";
...
return Redirect(viewUrl.Url);
Here I want to get that signed document in response instead of email. How this is possible? or is there any other way to get signed document after finish signature process?
You would make the API call to the "document" resource (.../documents/{documentId or constant}).
The post-signing redirect URL is for the purposes of continuing your web workflow. The "event" parameter allows your web application to generate the correct page or results. For example, in the "Loan Co" example at the Dev Center generates a post-signing page that has links for the document, which in turn result in the API call to retrieve the document. In a real-world integration, the redirect URL is not a reliable indicator that the envelope is "completed". For example, the signer could close the browser before the redirect was executed, or the envelope may have subsequent signers. The Connect service provides a much more reliable trigger for downloading the documents.
Expanding on what #WTP mentioned, you have a couple of approaches. First is via a raw API call using the /v2/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId} endpoint and retrieving the file from the response. More information can be found here.
Another option you may or may not be aware of is using the DocuSign Client NuGet package. Your code would then look something like this pseudocode:
Stream documentStream = EnvelopesApi.GetDocument(accountId, envelopeId, documentId);
If you are not using the NuGet package yet, keep in mind there is setup work that you will have to do to set-up the EnvelopesApi. That information can be found here.
I'm trying to make an API call using the simplest way possible:
<img src="http://IP-ADDRESS-TO-API/api/call/camera=1">
<img src="http://IP-ADDRESS-TO-API/api/call/camera=2">
IN CHROME: (the above code will pull the first image, but not the second almost every time)
IN EXPLORER: (the above code will only pull the first image AFTER prompting the user for the username and password)
The 'IP-ADDRESS-TO-API' is actually not the same IP or domain as where I'm calling it from. If I call the address from an AJAX call, I get a No 'Access-Control-Allow-Origin' header error.
I'm attempting to call this via C# to see if it can bypass this with the proper header sent in. Is there anyway to call this API call while passing in a username and password?
I've looked at examples of doing this via WebRequest but sadly, I can't see any methods of passing in credentials via the call itself. This as well as actually returning a proper image back to the DOM. Can anyone help?
Have you looked at the Credentials property of the System.Net.HttpWebRequest object?
I am trying to use FileMaker's XML WebPublishing feature. When I try to request a database from filemaker via Mozilla I get a user/pass request..when I enter that info the XML file loads. When I try this on IE, I get a blank result.
I then tried to use c#'s webrequest function to load the URI and I am getting a blank result when using the network credentials, when i omit the credentials I get a 401 unauthorized error (expected); I can't seem to figure out why I am getting a blank result.
I'm not sure if this will work, but have you tried inserting the credentials into the URL?
http://user#password:server.company.com/fmi/xml/fmresultset.xml?-db=...
There was a same question, how to get data from FileMaker database. I know 3 solutions:
1. FileMaker php Api. Use to create web service between database and your application
2. FileMaker XML Api. It's easier than first solution, and no need know php.
3. Now open sourced RESTfm project that uses XML and php api's and create a simple web service to fetch data in JSON format.
Hope it will help you.
I'm working on an application allowing users to sign in and register using Google and Yahoo through OpenID using ASP.NET MVC4, and the DotNetOpenAuth library. Google is working fine, and Yahoo was working fine for a few months as well until a few days ago.
For some reason, using my local version of IE 11, after authenticating with Yahoo, two responses are sent back to the web server, and each is validated in its own separate thread. One response is determined to be valid, and the other response is determined to be invalid because the first response is already validated. The responses are then sent back to the user, and depending on which one is sent first, two very different outcomes can occur.
Using Chrome and Firefox works correctly. Yahoo is returning only one response. Using different versions of IE on other machines (including 11) work correctly as well. Using fiddler, I've verified that the correct requests are being sent out. I've tried clearing my cache, disabling any addons, and changing document and browser modes using the dev tools, and no luck. Is there anything that can be causing two responses to be sent back?
The basic code to send the request is below. The config file is using all default values.
OpenIdRelyingParty openid = new OpenIdRelyingParty();
IAuthenticationRequest request = openid.CreateRequest(Identifier.Parse("https://me.yahoo.com"));
var fields = new ClaimsRequest();
fields.Email = DemandLevel.Require;
request.AddExtension(fields);
return request.RedirectingResponse.AsActionResult();
It turns out that the problem was that I was sending a request to tell Yahoo to redirect back to an unencrypted connection after authentication. If I tell Yahoo to return to an https url, rather than http, everything works correctly, and I only get one request coming back to the application.