Search code examples
reactjsnext.jsonedrivefilepicker

retrive file from one drive from a next.js application

I am using react-onedrive-filepicker to retrieve file content from a selected file located on OneDrive.

My code is like:

<ReactOneDriveFilePicker
 clientID={process.env.NEXT_PUBLIC_MICROSOFT_CLIENT_ID}
 action="query"
 multiSelect={false}
 advanced={{
     redirectUri: "https://graph.microsoft.com/v1.0/me/"
 }}
 onSuccess={(result) => {
     alert(JSON.stringify(result));
 }}
 onCancel={(result) => {
     alert(JSON.stringify(result));
 }}
>
 <Button className="btn btn-md btn-primary">MSOneDrive</Button>
</ReactOneDriveFilePicker>

I am actually getting this error

error message

I am at a loss here, because I have no idea what URI is supposed to expect nor how to pass it... I have registered https://login.live.com/oauth20_desktop.srf on my Azure app, but it appears not to be the right address to show a user's OneDrive folder...

Where am I going wrong here?

I have also opened a issue on the react-onedrive-filepicker GitHub, but I am afraid the repo might be unmaintained..

EDIT

I am now passing the redirectUri value for MS Graph to the component, but it claims that redirect uri is not in the same domain as picker sdk... Now, it looks like a never-ending loop:

  • I cannot put the page URL where the picker is hosted, because it is a dynamic address...
  • but even if I put there the local URI, what's the point? I won't see the OneDrive files of my user...

What is impressive is how easy it is to make the Google picker work, and how incredibly difficult it is to make the MS work...

Solution

  • TL;DR

    Your apps URL should be the path at which you can access your app in the browser. This URL has to be registered as redirect URI both in the Azure client configuration as well as in your ReactOneDriveFilePicker component.

    To access Microsoft APIs, there are different steps to follow. First, you have to register your application with Microsoft. Then the user authorizes your application to access their data and only then you are allowed to access the files. Your struggles may actually come from the authorization step. Microsoft uses the OAuth protocol for managing access to their API resources (Docs: Auth and available auth flows), during which the user gets redirected to the Microsoft site, authorizes your app and gets redirected back to your application:

    the oauth flow (diagram by ArchitectXChange.com)

    Only then, you can access the API resources, in your case the OneDrive files.

    The redirect URI now refers to the exact address your file picker is located at. Lets say you are running your application on localhost with the path /onedrive-filepicker, then your redirect URI will be http://localhost/onedrive-filepicker, since this is the place your button is located at. Now you have to put this URL into the app registration with Azure, so that Azure makes sure no one is kidding around on behalf of your application. And of course you have to confirm the redirect URI when calling the API using the redirectUri property.

    You can find more on this in the OneDrive File Picker SDK docs and on their set up section.

    EDIT: If you have a dynamic url for your picker, you will need some fixed redirect route. This can be http://localhost/redirect. Before starting the Auth flow, you have to store the current state/route, e.g. inside local storage. After the redirect, you finish the authorization and redirect the user once again to the previously stored state/route.

    The point on redirecting the user to your own application and not to their OneDrive is, that your application wants to access the files. If the user gets redirected to OneDrive, maybe they will see their files, but OneDrive will not know how to send the information back to your app. If you redirect to your app, it stays in control of the UI, can prompt the user to select a file and receive the selected file using the OneDrive SDK.

    Maybe it will help you to follow along the Microsoft docs to use the SDK right away instead of building up on an undocumented third-party component.