Office 365 REST Calendar API for creating events failing with HTTP - 403 when authenticated using OAuth bearer token - api

My azure hosted web API uses the O365 Calendar and Mail REST APIs for creating events and mails on behalf of the users. All necessary permissions have been enabled for the corresponding Azure AD application. My question - Accessing the mail API using the Bearer OAuth token as part of the header succeeds but when I use the same token for the events API, it fails with a 403.
The Documentation I have been following for my implementation is the official msdn one and the update - https://social.msdn.microsoft.com/Forums/exchange/en-US/6fc135ae-f8f9-4b4d-b50b-f00a2bd79a30/office-365-rest-api-mail-calendar-contacts-update?forum=exchangesvrdevelopment
Fiddler trace (Raw view of request) -
POST https://outlook.office365.com/ews/OData/Me/Events HTTP/1.1
Accept: application/json
client-request-id: 00000000-0000-0000-0000-000000000000
Authorization: Bearer <OAuth token>
Content-Type: application/json; charset=utf-8
Host: outlook.office365.com
Content-Length: 287
Expect: 100-continue
{"Attendees":[{"EmailAddress":{"Address":"sample#sample.com","Name":null},"Type":"Required"}],"Body":{"Content":"Hello World","ContentType":"HTML"},"End":"2014-10-22T19:00:00Z","Location":{"DisplayName":"Conf Room M"},"Start":"2014-10-22T18:00:00Z","Subject":"Testing"}
Text view of response -
{"error":{"code":"ErrorAccessDenied","message":"Access is denied. Check credentials and try again."}}
Fiddler trace of the Mail API request that works fine -
POST https://outlook.office365.com/ews/OData/Me/sendmail HTTP/1.1
Accept: application/json
client-request-id: 00000000-0000-0000-0000-000000000000
Authorization: Bearer <OAuth Token>
Content-Type: application/json; charset=utf-8
Host: outlook.office365.com
Content-Length: 171
Expect: 100-continue
Connection: Keep-Alive
{"Message":{"Body":{"Content":"Test","ContentType":"HTML"},"Subject":"test","ToRecipients":[{"EmailAddress":{"Address":"sample#sample.com","Name":null}}]}}

Considering that you are getting a 403 (Forbidden) error for one API, I'd suggest you review the resources enabled for the application. Can you make sure you have Write permissions for the Calendar API? I know you mentioned that you've done this before, I'm just checking in case of the small chance you missed those Write perms.

Sorry for having kept this question hanging.
The issue was with the ClientSecret (either had stale permissions on it or was wrong in the first place). Generating a new one via the management portal fixed this issue.

Related

Attach a file (picture) to a conversation

I would like to be able to attach a file to a conversation, using the REST API. Is it possible? There is a «attachments» to /conversations/{convId}/messages/{itemId} but is that usable? How? The description of that field is not available.
The file API of Circuit supports the upload of attachments. As soon as you received your access token you can POST a message with the byte data. The following example wold upload a file with name test.jpg
POST /rest/v2/fileapi HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Content-Length: 100
Content-Disposition: attachment; filename="test.jpg"
Cache-Control: no-cache
<your content in binary form here>
Usually I am using Postman for my tests since it is very easy to use and supports OAuth 2.0 token generation (https://www.getpostman.com/)
You will receive an result that looks like
{"fileId":"fb211fd6-df53-4b82-824d-986dac47b3e7","attachmentId":"ZmIyMT..."}
If you want to validate your upload you can check it via
GET /rest/v2/fileapi?fileid=fb211fd6-df53-4b82-824d-986dac47b3e7 HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Cache-Control: no-cache
Well that was the easy part, now that you have uploaded the file to the backend you must attach it to a conversation item. Today we do not support UPDATE, i.e. you need to create a new one.
POST /rest/v2/conversations/<conv ID>/messages HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
content=New+Text+Message&attachments=ZmIyMT...
You have to pass the generated attachment ID. After the execution of this requests the file is attached to the conversation.
If you skip the second step the file will not be linked to any conversation, is only accessible by the user who initiates the upload and will be deleted within the next 24 - 48h automatically.
Hope this helps, let me know if you have additional questions.

Web API Basic Authentication returns 401

I've build a web api service with basic authentication and using a global DelegatingHandler implementation which I hook up to the web API GlobalConfiguration, in order to extract the username:password credentials from the request and hook an IPrincipal to the HttpContext if the credentials map to a valid user.
I've tested my api thoroughly on localhost and it's working fine, but not quite when hosted on IIS on a VPS.
I've hooked up remote debugging on the VPS in order to inspect whats going on and it turns out that whenever I include the authorization header to my request, the breakpoints I have set on the message handler are not getting hit, meaning that the request does not reach the handler. If I remove the Authorization header from the request, the breakpoint is getting hit and the handler is able to process it.
Since the message handlers are the first that will process the request in the pipeline (from what I know of, correct me if I'm wrong) I guess there must be an IIS or setup issue that I'm not aware of that messes the authentication process.
Fiddler Request Headers
GET http://myip/api/v1/route/parameter HTTP/1.1
Content-Type: application/json; charset=utf-8
Authorization: Basic ZHJpdmVyOjEwMTAyMDAz
Host: myip
Fiddler Response Headers
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Basic realm="myip"
X-Powered-By: ASP.NET
Date: Mon, 22 Aug 2016 15:04:15 GMT
Content-Length: 61
{"Message":"Authorization has been denied for this request."}
What could be possibly be wrong, where should I look at for a solution?
EDIT
Had to disable Basic Authentication from the Authentication menu on the right pane setting for the IIS application.

Datastore API always returning "dsid: Missing Value" error

I'm trying to follow the datastore API tutorial and this simple request (sent via Fiddler):
POST https://api.dropbox.com/1/datastores/get_or_create_datastore HTTP/1.1
User-Agent: Fiddler
Host: api.dropbox.com
Content-Length: 12
Authorization: Bearer [snipped]
dsid=default
always results in this error response:
HTTP/1.1 400 Bad Request
{"error": {"dsid": "Missing value"}}
The access token was created from the developer app console, and my test app has full dropbox permissions. Running the list_datastores API call succeeds and reports that I do have one datastore with a dsid of default.
I think you'll need a header of Content-Type: application/x-www-form-url-encoded, since you're sending form-encoded parameters.

Google API access token returning 400 - "invalid_request"

I'm making the following request to google oauth2 to get the access token and am getting the 400 http response with "invalid_request":
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Connection: keep-alive
Accept: */*
User-Agent: NING/1.0
Content-Length: 260
Content-Type: application/x-www-form-urlencoded
With the following parameters in the request body:
Map(redirect_uri -> http%3A%2F%2Flocalhost%3A8080%2Foauth%2Fgsheet, client_id -> _.apps.googleusercontent.com, code -> 4/9hzannwi_UlYWFlFEivgYXKzdGs6._, client_secret -> _, grant_type -> authorization_code)
This is really bugging me, any help/advice is greatly appreciated.
I was encoding the redirect_uri prior to making the request which was causing an issue. Not doing this solved the problem. This seems odd however as I encode the redirect_uri when sending the user to the oauth2 request page...

twitter api issue

I'm integrating "Sign in with twitter account" function at my site.
So, I'm sending request to https ://twitter.com/oauth/request_token, getting token, making redirect to https ://twitter.com/oauth/authenticate?oauth_token=%oauth_token%
Then I recieving call back with oauth_token and oauth_verifier
This goes fine.
But than I need to call https ://api.twitter.com/1/account/verify_credentials.json to get authorizated client details
I'm sending:
GET https ://api.twitter.com/1/account/verify_credentials.json
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: q=0.8,en-us;q=0.5,en;q=0.3
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
X-Auth-Service-Provider: https ://api.twitter.com/1/account/verify_credentials.json
X-Verify-Credentials-Authorization: OAuth realm="http://api.twitter.com/", oauth_signature="acYFjEgUrTcyb4FMBoJF8MlwZGw%3D", oauth_timestamp="1286899670", oauth_consumer_key="%CONSUMER_KEY%", oauth_nonce="268310006", oauth_token="%oauth_token%", oauth_version="1.0", oauth_signature_method="HMAC-SHA1"
%oauth_token% - token got when twitter redirects me back the cleint
%CONSUMER_KEY% - my twitter account's consumer key
And getting back
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache, max-age=300
Connection: close
Date: Tue, 12 Oct 2010 16:07:45 GMT
Server: hi
Vary: Accept-Encoding
WWW-Authenticate: Basic realm="Twitter API"
{"error":"Could not authenticate you.","request":"/1/account/verify_credentials.json"}
Can anyone plz advice me what's wrong here?
Thanks!
After you receive the callback you have to make request to POST oauth/access_token to exchange the temporary request_token for a permanent access_token associated with the user. Once you receive the access_token you can perform the GET account/verify_credentials request.
Here is a good flow chart explaining how the full OAuth process works.
Flow Chart
It sounds like you're two thirds of the way through the authentication. Now you need to exchange your authorised request token for a permanent access token.
You are using header to pass parameters (X-Verify-Credentials-Authorization), instead you should be using GET method. If you are using php Zend framework's OAuth component, then it should look like
$client->setMethod(Zend_Http_Client::GET);