I'm trying to use Javascript Preview SDK to read all files in box account from my web application. I would like to see a preview of all files on my box account from my custom web application. There is some way to use a default ID that allow me to read all folders and files in the box account?
Currently, I'm trying to use:
Box.Preview.show('FILE_ID',{
token: access_token,
container: '.preview-container',
showDownload: true
});
The access_token is obtained through the procedures described in this page. Besides, using the code above I obtain this error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 404. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
How can I set request header using Javascript Preview SDK?
Thank for the response.
You have to add the URL of your app (http://localhost:3000) to the CORS Allowed Origins text area. You can find this field in the form you used to create your application, the same form where you also obtained the Developer token. Note: Avoid the use of trailing slashes in the URL.
Related
I have an application which is uploading objects to Google Cloud Storage using signed URLs and I'd like to know if it's possible to make the object public during the sign/upload step.
I know it's possible to make the object publicly visible by setting the policy on its bucket or by using the client library/making a REST request after it's been uploaded, but in order to minimize the impact on my workflow, I'd like to do it all in one go. Is this possible? If it can be done, I'm assuming it's by setting a header when signing the URL or when making the REST request using the signed URL but I haven't been able to find documentation which covers this.
UPDATE:
I've just found the Extension/Custom Headers section of the XML API docs which claims that this can be achieved using the x-goog-acl header (e.g. x-goog-acl: public-read). Unfortunately, this does not work. The object is not publicly visible after setting the header when signing the URL and when uploading the file.
Quoting the Cloud Storage documenation regarding Signed URLs:
When specifying the name:value pairs for headers, keep in mind the following:
Remove any whitespace around the colon that appears after the header name.
For example, using the custom header x-goog-acl: private without removing the space after the colon returns a 403 Forbidden error, because the request signature you calculate does not match the signature Google calculates.
So the solution could be setting the header value as x-goog-acl:public-read instead of x-goog-acl: public-read.
I keep receiving the error below when I use Ionic Serve...
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access.
It only occurs with "post" request. The "get" requests I have work with no error. I've seen documentation for proxy's but I was not looking to go that route. I'm currently using the CORS Chrome plugin as a workaround right now, but will be shipping to mobile soon (Ionic view) for testing, which I believe I will still run into the CORS issue using Ionic View.
I have control of the API/server - using nginx.
Any suggestions?
Cors will not affect to mobile phone. The issue is in POST method in web view. In Post methods Browser send OPTIONS Request for security Purpose. It should handle in API. I used ASP.NET WEB API When Using localhost I Used Two Methods for post in Same Name but it's not proper way for doing this. You need to handle in Configuration to Igonre this. If you have API without parameters add headers "content-type x-www-form-urlencoded" to you request header. If there are parameters. use another method without parameters using same name.(Method overloadin). But when you are using livehost don't forget to remove redundant methods.
I have html code containing FB profile pictures/clicable and etc/.
Using
fb:profile-pic and FB.XFBML.parse
I receive image url with HTTP. To have HTTPS I'm using:
https://graph.facebook.com/user_id/picture?return_ssl_resources=1
but have to generate code to make image clickable and add other attributes existing in fb-profile-pic.
I wrote this code 4 months ago.
Now I'm seeing fb:profile-pic is returning HTTPS link to image. Nothing is mentioned in FB documentation about change in behaviour/HTTP or HTTPS/.
Does anybody know about current state FB.XFBML.parse - secure or non secure links?
By default the protocol of the returned profile picture URL is the same as the protocol used to request the image.
So https://graph.facebook.com/zuck/picture will return the SSL version of Mark’s profile picture, while http://graph.facebook.com/zuck/picture will return an HTTP URL.
return_ssl_resources can be used with both, with value 0 for an HTTP and 1 for an HTTPS URL.
Does anybody know about current state FB.XFBML.parse - secure or non secure links?
I think the JS SDK should be able to decide this automatically, based upon the protocol the embedding page was requested with.
There are many other question related to this, but they didn't help me fix my problem.
I'm using the Facebook server-side login for a website, which I want to test locally. The path that initiates the login action is [http://localhost:8080/fblogin] (this redirects to the Facebook login dialogue, and goes from there).
I can successfully get the code, but when I try to exchange that for an access token, I get the following error:
{"error":{"message":"Missing redirect_uri parameter.","type":"OAuthException","code":191}}
I am providing the redirect_uri, url encoded and it is the same as the one I use to get the first code. Here is the url I'm using to request the access token (with the all-caps query string parameters replaced with their actual values, of course):
https://graph.facebook.com/oauth/access_token?client_id=CLIENT_ID&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Ffblogin&client_secret=CLIENT_SECRET&code=CODE_FROM_FB
I suspect this might have to do with how my app is set up on Facebook. Here are the values I have set:
Display Name: (an actual display name here)
App Domains: localhost
Contact email: (an actual email here)
Site URL: [http://localhost:8080/fblogin]
What do I need to tweak in the settings to get this to work? Or does this look correct?
By the way, if it makes any difference, I am using the Play! framework, version 2.0.1
After digging around a little more, I found that it was necessary for me to use POST when sending the request from my server to get the access token.
Interesting that using POST worked for you as this didn't for me.
In any case, did you add the query parameters using setQueryParameter()? (see How to make multiple http requests in play 2?)
According to this Microsoft api page
http ://msdn.microsoft.com/en-us/library/live/hh826522#reading_albums
, I tried to translate this browser access skydrive URL
https://skydrive.live.com/?cid=0A263A7CBEAAFB80&sc=photos#cid=0A263A7CBEAAFB80&id=A263A7CBEAAFB80%214521&sc=photos
to
http://apis.live.net/v5.0/folder.0A263A7CBEAAFB80.A263A7CBEAAFB80!4521
Since the album is shared to public, I should be allowed to access without access token.Am I missed something? Or is just using the wrong URL?
I notice I can get public profile by using this
https ://apis.live.net/v5.0/0A263A7CBEAAFB80/
And I have read the REST API
http ://msdn.microsoft.com/en-us/library/live/hh243648.aspx
, but I found it is hard to deduce the correct url format
This get all albums
https ://apis.live.net/v5.0/0A263A7CBEAAFB80/albums
REST URL also fails.
I've been looking for a guide for this as well, but just noticed that your URL appears to have an additional '/' in it. The one listed on the site is:
https://apis.live.netv5.0/%fileid%
Were you able to get this to work?