Signing users in to OneDrive (Web apps)
Let users sign in to their Microsoft OneDrive service from your web apps.
Microsoft Visual Studio2013
Register your app and configure its settings
Go to the Microsoft account Developer Center.
If prompted, sign in with your Microsoft account credentials.
If you are not immediately prompted to provide the app's display name and primary language, click Create application.
Type the app's display name and select the app's primary language.
Specify a redirect domain and get a client secret
In the Microsoft account Developer Center, select your app and click Edit settings > API Settings.
Under Redirect URLs, type the redirect domain you will be redirecting users to
Click App Settings. On the application summary page, the client secret is displayed. It should look something like this:
To change your client secret, click App Settings > Create a new client secret > OK. Both the old and new client secrets will continue to work until you activate the new client secret from API Settings in the Microsoft account Developer Center.
Here's the basic code that shows how to reference the Live SDK, invite a user to sign in, get the signed-in user's permission to get his or her basic profile info, and display a greeting with the signed-in user's first and last names. This example calls WL.Event.subscribe and WL.init to initialize the sign-in, and WL.ui to sign the user in.
<!DOCTYPE html> <html> <head> <title></title> </head> <body> <script src="//js.live.net/v5.0/wl.js"></script> </body> </html>
constants.js (Replace YOUR_CLIENT_ID with your app's client ID and YOUR_REDIRECT_URL with your app's redirect URL.)
var APP_CLIENT_ID = "YOUR_CLIENT_ID"; var REDIRECT_URL = "YOUR_REDIRECT_URL";
Testing web apps locally
When you are developing a web app, it is convenient to test the app on a local computer before you deploy it to a web server. However, the Live Connect APIs require the redirect URL to use the same domain at which the app's client ID was configured. Your local computer's web server probably uses a default address like http://localhost, so you must map your domain to the Internet Protocol (IP) address of your local web server. To do this, you add a mapping to the hosts file on your computer. (The job of the hosts file is to map host names to IP addresses.) On Windows computers, the hosts file is located at \Windows\System32\drivers\etc\hosts. On Mac OS X and most Unix computers, it is located at /private/etc/hosts. The format is the IP address, followed by the domain to map, like this.
127.0.0.1 MyDomain.com 127.0.0.1 AnotherDomain.com
The preceding example demonstrates mapping two arbitrary domain names to the Internet Protocol (IP) address for localhost. With these mappings in place, every time you navigate to MyDomain.com or AnotherDomain.com, you will be redirected to 127.0.0.1 (http://localhost). The mappings in the hosts file apply to all web navigation, including redirect URLs that are returned by the service. This works because the service integrated with Microsoft account does not check the actual IP address that is in use, the APIs only verify the domain name. If your client ID was configured with a redirect URL of http://MyTestingDomain.com/MyApp/callback.htm, you update your hosts file with the following mapping: 127.0.0.1 MyTestingDomain.com. Now if you enter "MyTestingDomain.com" into your browser, it will resolve to http://localhost, so you can use your local web server for testing.
Elevated (or root) privileges are required to edit the hosts file, regardless of platform. You can map an externally available domain to your local server IP address, but you must comment out the mapping when you want to view the actual website. This applies only to the computer on which the hosts file was modified. This is a handy trick because it makes it easy to switch between your externally available website and your local test website.