I’m pulling my hair out over this, maybe someone has an idea. We have a web application, registered with Azure, that is grabbing calendar and event data from the Office 365 API that pertains to the logged in user’s account.
When a user logs on to our system, we get the refresh token and access + ID tokens from Office365 API. I can send the access token directly to the server and I can see the users events, things are working properly. The “base” oauth code is lifted from the sample code here . We can also do this from within our application and it is also working properly.
This works properly for certain users, but not for other users. For those users, the system authenticates their token, but responds a NULL value in the “value” key on the reponse.
- The subscription types between working users and non-working users are identical (E1).
- The code that handles the calls does not change, there is no additional process that “specific users” go through. They are all treated the same by our local system.
- There are no environmental or variable differences. Some accounts will retrieve their events, other accounts get a NULL response. Even on the same computer.
- There are valid calendar events or messages in every case.
The exact server response we get is this, which happens after the access token is authenticated:
(string(196) "{"@odata.context":"https : //outlook.office.com/api/v1.0/$metadata#Me/Events","value":[{"error":{"code":"ErrorInternalServerError","message":"Object reference not set to an instance of an object."}}")
(spaces added after https due to reputation)
If I log in as a user on the oauth sandbox (https://oauthplay.azurewebsites.net/) the system WILL return the proper results in every case. It leads me to believe that the access token Office365 passes us is not correct, but it only seems to fail in certain situations with no common link between those users.
I’m trying to come up with any possible reason this could happen. If anyone has any ideas I’m all ears.
Advertisement
Answer
Well, I haven’t found a good answer as to why this was happening, but we changed the endpoint instead of /events/ to /calendarview/?{params} and everything seemed to work like magic.
Knowing this, I would be interested to know why /events/ only worked for certain users and not others. Maybe this will help someone in the future.