I have an application that used SkyDrive API. After SkyDrive was replaced I upgraded my code to use OneDrive API.
Looking my application in the dev page (https://account.live.com/consent/Manage) I could notice that the scopes I used with SkyDrive ("wl.offline_access", "wl.signin", "wl.basic", "wl.skydrive", "wl.skydrive_update") and the scopes I used with OneDrive ("onedrive.readwrite", "onedrive.appfolder", "wl.offline_access") were there.
Everything was working until last month, even with all these scopes. But now I'm not being able to upload files. I'm receiving a Bad Request error (Code 400).
I discovered that adding the ""onedrive.readonly" scope fix the upload but I don't know why. I also know that an application with only the OneDrive scopes ("onedrive.readwrite", "onedrive.appfolder", "wl.offline_access") also works.
Does anybody knows what's going on?
Check if the oAuth token has Files.ReadWrite capability using
http://jwt.calebb.net/.
If not present, when you are logging in the user, give the scope while obtaining code as
files.readwrite.all offline_access
Related
I'm trying to use Gmail API for my web app. What I want is get messages which has attachment file and I'm following this tutoral.
The problem is when I use 'q' parameter, it return the error: Metadata scope does not support 'q' parameter
My request URL
Note: My authorize scopes are:
https://mail.google.com/
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/gmail.readonly
The error message occurs when https://www.googleapis.com/auth/gmail.metadata is included in the scopes. But in your scopes, it is not used. So please confirm the following points again.
If the refresh token is retrieved in your script, please remove it and authorize again using the scopes without https://www.googleapis.com/auth/gmail.metadata.
If you use Google APIs Explorer, please remove Google APIs Explorer at https://myaccount.google.com/permissions.
Please login and remove it.
After you did above, please use the API of endpoint by authorizing using the scopes without https://www.googleapis.com/auth/gmail.metadata.
If this was not useful for you, I'm sorry.
I would like to use server-side flow to get read access to user's spaces.
Here is my login URL
https://podio.com/oauth/authorize?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=space:read
But Podio asking me full permission.
I tried different options
https://developers.podio.com/authentication/scopes
The scope argument is currently in Beta only and therefore not available for everybody. We still have some work to do on the granular authentication project before we are able to release it to public.
My question seems similar to OneDrive for Business REST API - PUT,POST - 401 Unauthorized
However, instead of uploading, I am trying to download a file. What's strange is that I do get the file contents and data, but the response code is a 401.
Any idea why? Of course, I would like to be receiving a 200 and not have to ignore the response code.
As far as my Azure AD app permissions go, I am allowing pretty much all read permissions under delegated permissions for Office 365. I have listed all the permissions I selected here, for your reference.
Delegated Permissions I am allowing for Office 365:
Read managed metadata
Run search queries as a user
Read items in all site collections
Read user files
Delegated Permissions I am allowing for Windows Azure Active Directory:
Enable sign-on and read users' profiles
I have not enabled anything under Application Permissions.
There is a bug in our implementation - if you provide an Authorization: header with a bearer token on the download URL (which is pre-authenticate) the service rejects the authentication (hence the 401) but since the URL is pre-authenticated, the contents of the file are still sent.
We're working on a fix. You can track the status by watching this issue on our GitHub repo: https://github.com/OneDrive/onedrive-api-docs/issues/189
my app was pulling feeds to my site for over a year, and recently stopped working late this month(23/03/2015).
I debugged the application, and still don't know why my access token is reported malformed. Here is a sample of a token which to me perplexes me as at the end there is a # tag in it, something I don't expect with QueryString access tokens:
AQD2pAp0kqILBZ9ysXGarDVdmcnnknRgnLvnLdml2TuiLXH8grq8mHkyBCE3jjoEahyMl17myD7ldp1DDWRYEIP9EEnwSHUU5-sZk3mZv6p5YTLpfTVQntYeuuYbIYEn13e3PkF2_cCQbRU2R769xr_Cj0j3Gf_HygWElOQq3BtivxTgN4Db1HfEzrIpnR7309sAZAwKJKbTGw07KukL51oVn1di0gcO2dn5ffv5V4MEb4RuVLLNrcjZWbVPB7Ktyiy62Gw-64ypMqyx2zj_0quZKFlgV0fBE_TY3K_iMr-XEGuodId1hk0n7k89DUjXa40#=
Looking at my application on Facebook(app), it is clear that I should expect access tokens on request from Query String.
Something is definitely wrong, as this access token reports a malformed access token. This is a recent bug that has just cropped up so I think.
Any body know about this problem? I can't access my feeds from my facebook profile using this access token to expose to my web based application.
Any help or suggestions are welcome.
Kind regards
Martin Okello.
Probably, you were using the read_stream permission which is no longer granted to apps. You should try to regenerated an Access Token with the new user_posts permission and use this Access Token instead.
See
https://developers.facebook.com/docs/apps/changelog#v2_3_new_features
https://developers.facebook.com/docs/facebook-login/permissions/v2.3#reference-read_stream
I want to integrate SkyDrive with single sign on in which users has to sign in and give consent only once in our website. After that they can access their SkyDrive files/folders to upload seamlessly.
I have created my application and did all app settings as mentioned in http://msdn.microsoft.com/en-us/library/dn659751.aspx.
I followed sample in link https://github.com/liveservices/LiveSDK-for-Windows/tree/master/src/Web/Samples/OAuthServer/Asp.net/OAuthSample
But I am getting 400 error bad request when I use REST API to get access token and refresh token.
can someone help please?
This may be a Redirect Url issue. Can you check to see if the Redirect Url that you're using is the same in the following 2 places:
When you created the app (in your app settings page -
https://account.live.com/developers/applications/summary/YOUR_APP_ID)
The redirectUrl passed as parameter in your REST API call. (GET
https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPES&response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL)