Posted   by 

Windows App Permission Manager

Shortcut of Permission Manager (App Ops) for Android 4.3. Permission Manager (App Ops) is a new feature introduced by Android 4.3 to manage permissions of apps without root permission. It can help you to secure your android device and protect your privacy without ROOT. Oct 28, 2016  Starting with Windows 8, one of the main selling points of Windows 8 and 10 is the modern apps and how they make things easier for you. However, unlike in Android where every app you install will ask for your permission to access certain content and settings, Windows 10 provides an app with all the permissions upfront when it is installed. Pages Manager for Facebook is the only fully featured Facebook Pages Manager app on Windows that you can use to manage all your Facebook pages. The app allows you to post, delete or share your pages status, upload photos, send and receive messages from your pages, comment on your posts or reply to a comment and a lot more. This blog was written by Jon Kay, Program Manager, Location Team. We have made big investments in Windows 10 to unify the Windows and Windows Phone app platform. Based on user and developer feedback, consent prompting for location has been improved and simplified from Windows Phone 8/8.1.

-->

This article describes how to use the AccountsSettingsPane to connect your Universal Windows Platform (UWP) app to external identity providers, like Microsoft or Facebook, using the Windows 10 Web Account Manager APIs. You'll learn how to request a user's permission to use their Microsoft account, obtain an access token, and use it to perform basic operations (like get profile data or upload files to their OneDrive account). The steps are similar for getting user permission and access with any identity provider that supports the Web Account Manager.

Note

For a complete code sample, see the WebAccountManagement sample on GitHub.

Get set up

First, create a new, blank app in Visual Studio.

Second, in order to connect to identity providers, you'll need to associate your app with the Store. To do this, right click your project, choose Store > Associate app with the store, and follow the wizard's instructions.

Third, create a very basic UI consisting of a simple XAML button and two text boxes.

And an event handler attached to your button in the code-behind:

Lastly, add the following namespaces so you don't have to worry about any reference issues later:

Show the accounts settings pane

The system provides a built-in user interface for managing identity providers and web accounts called AccountsSettingsPane. You can show it like this:

If you run your app and click the 'Log in' button, it should display an empty window.

The pane is empty because the system only provides a UI shell - it's up to the developer to programatically populate the pane with the identity providers.

Tip

Optionally, you can use ShowAddAccountAsync instead of Show, which will return an IAsyncAction, to query for the status of the operation.

Register for AccountCommandsRequested

To add commands to the pane, we start by registering for the AccountCommandsRequested event handler. This tells the system to run our build logic when the user asks to see the pane (e.g., clicks our XAML button).

In your code behind, override the OnNavigatedTo and OnNavigatedFrom events and add the following code to them:

Users don't interact with accounts very often, so registering and deregistering your event handler in this fashion helps prevent memory leaks. This way, your customized pane is only in memory when there's a high chance a user is going to ask for it (because they're on a 'settings' or 'login' page, for example).

Build the account settings pane

The BuildPaneAsync method is called whenever the AccountsSettingsPane is shown. This is where we'll put the code to customize the commands shown in the pane.

Start by obtaining a deferral. This tells the system to delay showing the AccountsSettingsPane until we're finished building it.

Next, get a provider using the WebAuthenticationCoreManager.FindAccountProviderAsync method. The URL for the provider varies based on the provider and can be found in the provider's documentation. For Microsoft Accounts and Azure Active Directory, it's 'https://login.microsoft.com'.

Notice that we also pass the string 'consumers' to the optional authority parameter. This is because Microsoft provides two different types of authentication - Microsoft Accounts (MSA) for 'consumers', and Azure Active Directory (AAD) for 'organizations'. The 'consumers' authority indicates we want the MSA option. If you're developing an enterprise app, use the string 'organizations' instead.

Finally, add the provider to the AccountsSettingsPane by creating a new WebAccountProviderCommand like this:

The GetMsaToken method we passed to our new WebAccountProviderCommand doesn't exist yet (we'll build that in the next step), so feel free to add it as an empty method for now.

Run the above code and your pane should look something like this:

Request a token

Once we have the Microsoft Account option displaying in the AccountsSettingsPane, we need to handle what happens when the user selects it. We registered our GetMsaToken method to fire when the user chooses to log in with their Microsoft Account, so we'll obtain the token there.

To obtain a token, use the RequestTokenAsync method like this:

In this example, we pass the string 'wl.basic' to the scope parameter. Scope represents the type of information you are requesting from the providing service on a specific user. Certain scopes provide access only to a user's basic information, like name and email address, while other scopes might grant access to sensitive information such as the user's photos or email inbox. Generally, your app should use the least permissive scope necessary to achieve its function. Service providers will provide documentation on which scopes are needed to get tokens for use with their services.

  • For Office 365 and Outlook.com scopes, see Authenticate Office 365 and Outlook.com APIs using the v2.0 authentication endpoint.
  • For OneDrive scopes, see OneDrive authentication and sign-in.

Tip

Optionally, if your app uses a login hint (to populate the user field with a default email address) or other special property related to the sign-in experience, list it in the WebTokenRequest.AppProperties property. This will cause the system to ignore the property when caching the web account, which prevents account mismatches in the cache.

If you're developing an enterprise app, you'll likely want to connect to an Azure Active Directory (AAD) instance and use the Microsoft Graph API instead of regular MSA services. In this scenario, use the following code instead:

The rest of this article continues describing the MSA scenario, but the code for AAD is very similar. For more info on AAD/Graph, including a full sample on GitHub, see the Microsoft Graph documentation.

Use the token

The RequestTokenAsync method returns a WebTokenRequestResult object, which contains the results of your request. If your request was successful, it will contain a token.

Note

If you receive an error when requesting a token, make sure you've associated your app with the Store as described in step one. Your app won't be able to get a token if you skipped this step.

Once you have a token, you can use it to call your provider's API. In the code below, we'll call the user info Microsoft Live API to obtain basic information about the user and display it in our UI. Note however that in most cases it is recommended that you store the token once obtained and then use it in a separate method.

How you call various REST APIs varies between providers; see the provider's API documentation for information on how to use your token.

Windows App Permission Manager Free

Store the account for future use

Tokens are useful for immediately obtaining information about a user, but they usually have varying lifespans - MSA tokens, for instance, are only valid for a few hours. Fortunately, you don't need to re-show the AccountsSettingsPane each time a token expires. Once a user has authorized your app once, you can store the user's account information for future use.

To do this, use the WebAccount class. A WebAccount is returned by the same method you used to request the token:

Once you have a WebAccount instance, you can easily store it. In the following example, we use LocalSettings. For more information on using LocalSettings and other methods to store user data, see Store and retrieve app settings and data.

Then, we can use an asynchronous method like the following to attempt to obtain a token in the background with the stored WebAccount.

App

Place the above method just before the code that builds the AccountsSettingsPane. If the token is obtained in the background, there is no need to show the pane.

Because obtaining a token silently is very simple, you should use this process to refresh your token between sessions rather than caching an existing token (since that token might expire at any time).

Note

The example above only covers basic success and fail cases. Your app should also account for unusual scenarios (like a user revoking your app's permission or removing their account from Windows, for example) and handle them gracefully.

Firefox Permission Manager

Remove a stored account

If you persist a web account, you may want to give your users the ability to disassociate their account with your app. This way, they can effectively 'log out' of the app: their account information will no longer be loaded automatically upon launch. To do this, first remove any saved account and provider information from storage. Then call SignOutAsync to clear the cache and invalidate any existing tokens your app may have.

Add providers that don't support WebAccountManager

If you want to integrate authentication from a service into your app but that service doesn't support WebAccountManager - Google+ or Twitter, for example - you can still manually add that provider to the AccountsSettingsPane. To do so, create a new WebAccountProvider object and provide your own name and .png icon, then and add it to the WebAccountProviderCommands list. Here's some stub code:

Note

This only adds an icon to the AccountsSettingsPane and runs the method you specify when the icon is clicked (GetTwitterTokenAsync, in this case). You must provide the code that handles the actual authentication. For more information, see (Web authentication broker)[web-authentication-broker], which provides helper methods for authenticating using REST services.

Add a custom header

You can customize the account settings pane using the HeaderText property, like this:

Don't go overboard with header text; keep it short and sweet. If your login process is complicated and you need to display more information, link the user to a separate page using a custom link.

Windows App File Location

Add custom links

You can add custom commands to the AccountsSettingsPane, which appear as links below your supported WebAccountProviders. Custom commands are great for simple tasks related to user accounts, like displaying a privacy policy or launching a support page for users having trouble.

Here's an example:

Theoretically, you can use settings commands for anything. However, we suggest limiting their use to intuitive, account-related scenarios like those described above.

See also

This blog was written by Jon Kay, Program Manager, Location Team.

We have made big investments in Windows 10 to unify the Windows and Windows Phone app platform. Based on user and developer feedback, consent prompting for location has been improved and simplified from Windows Phone 8/8.1. These improvements are available now and apply to all apps running on a Windows 10 Mobile device, regardless of which OS version the app was created for.

Windows App Permission Manager Apk

Windows 10 provides a system-generated consent prompt when your apps first runs and a consolidated location permission settings page, both of which are detailed below. For apps existing that have custom permission prompts and/or custom ON/OFF permission settings, users will see both sets. This post gives details on the new prompt and settings and provides guidance on how to eliminate redundancy.

What’s New

  • The removal of location consent prompts in the Store prior to app install and app update. This allows users to more easily download your app and stay up to date.
  • The addition of system-provided runtime location consent prompts when location is first requested. This prompt will happen automatically on behalf of your app and you no longer need to create your own custom prompt and handle the logic behind it.
  • A new API, Geolocator.RequestAccessAsync, that allows you to request location access (see the sample). Note: The user is only prompted once per app. After the first time they grant or deny permission, this method no longer prompts for permission. Apps should call the RequestAccessAsync method before accessing the user’s location. In order to ensure the consent is shown the first time, your app must be in the foreground and RequestAccessAsync must be called from the UI thread. Until the user grants your app permission to their location, your app can’t access location data. To ensure back-compatibility for existing apps that do not use the new API, the new consent prompt will be fired automatically when app first tries to acquire the current location.
  • System provided per-app location ON/OFF toggles will appear in the Settings app (Settings>Privacy>Location) to allow users to control location permission on a per-app level. These show up automatically for all apps that have the location capability, so you no longer need to create your own custom ON/OFF toggles and handle the logic behind them. Note: The store policy requiring custom ON/OFF toggles within your app we will removed for Windows 10 Mobile when updated store policies are published next week.


Building an ideal user experience

All apps on Windows 10 Mobile that use location will benefit from these new improvements, whether the app was installed prior to upgrade to Windows 10, installed after upgrading, or installed on a fresh Windows 10 Mobile device. Here are some things you can do to make your app’s experience ideal for your users:

  • If you are building a Windows 10 package, remove your custom in-app location consent prompts and ON/OFF toggles and the logic behind them. Without doing so, users will experience double prompting (one prompt from the system and one prompt from your app) as well as have two ways to turn location ON/OFF that do not stay in sync with each other. Note that the system-provided controls will override your in-app control in the case the user turns the system provided toggle to OFF.
    • If your app is a Windows Phone 8 or Windows Phone 8.1 app, it is still required by policy to have a custom in-app location consent toggles (because the system settings on these operating systems do not include per-app toggles). To be compliant with policy as well as optimize for user experience, you may need to fork your package to have a new Windows 10 version. For guidance on managing multiple app packages, see here.
  • Be aware of when you first request location, the system-provided runtime prompt will appear. Depending on your app’s functionality, you may want to wait for a user to complete an action (e.g. logging in) before asking for location to avoid a prompt appearing while the user is mid-task.
  • Optional – monitor changes to permissions (see StatusChanged) and if desired, pop a message or prompt to your user and redirect them directly to the Location privacy settings to reconfigure the toggles using the URI: ms-settings:privacy-location.

The less-than-ideal user experience

For existing apps that have a custom location consent prompt, the user will see two similar prompts (one after the other) asking them the same thing, as seen below. Best practice is to remove the custom prompt.

For existing apps that have a location permission toggle in the app settings page, the user will have two places to change the settings (which can get out of sync). Best practice is to remove the in-app setting and defer to the new system settings page (Settings>Privacy>Location).

Summary and Additional Resources

This new location consent prompt approach is a large improvement because it enables a better user experience, removes a blocker to app install/update, and reduces the code needed for the enforcement of location permissions. We hope you enjoy it and welcome any feedback you may have.

  • Build 2015: Maps & Location Session Video (Geolocation topic starts at 13:15)