SuperApp:Authorization introduction

Preconditions

• During the initialization of the miniapp container SDK, the App developer must set the needAuthFromApp property to 'true' within either the EMASMiniAppInitConfig or MiniAppInitConfig class, then the wv.authorize will take effect and the miniapp needs to call wv.authorize before calling API to get device information.

• If the App developer doesn't set the needAuthFromApp property or set the needAuthFromApp property to 'false', the wv.authorize will not take effect and the miniapp can directly call API to get device information without user authorization.

Preparations

• When a miniapp invokes get-device-information-related APIs (such as WVLocation.getLocation, WVVideo.chooseVideo), the App must display an authorization prompt dialog requiring the user to decide whether to grant authorization to the current miniapp. miniapp developers can invoke wv.getSetting to check the current authorization status of the miniapp.

• When using APIs that require authorization, users must complete authorization at two distinct levels:

  1. Authorize the miniapp within the App;

  2. Enable the corresponding permission at the system level and authorize it to the App;

• The two levels of authorization status are independent of each other. If the miniapp has already obtained user authorization for accessing specific device information(such as location scope) , but the App itself hasn't acquired the corresponding system permissions, when the miniapp calls the corresponding JSAPI (such as WVLocation.getLocation), the miniapp container will automatically trigger a system dialog asking the user to confirm whether to grant permissions to the App. The miniapp can also use the WVUIDialog.showAuthGuide API to guide users to the system settings page to enable system permissions for the App.

Miniapp authorization related logic

When the miniapp has not been authorized by the user, calling a permission-requiring JSAPI requires first invoking wv.authorize. The App will then display an authorization prompt to the user:

• If the user consents, the miniapp can proceed to invoke the device-information-related API to execute its functionality, and subsequent calls to this API will no longer trigger an authorization dialog;

• If the user declines, the fail callback will be triggered immediately to indicate the authorization cancellation, and subsequent API calls will still prompt the user with an authorization dialog;

For APIs that require authorization and have not been authorized by the user for the miniapp, it is suggested to first use the wv.getting method to check, then call the wv.authorize method, and finally, call the API that requires authorization.

System-level permissions related logic

If a specific permission required by an API has not been enabled by the user in the system or granted to the app, even if the user consents to authorize this permission to the current miniapp, the API call will still fail. Typically, the miniapp's first call to this API will also trigger the App to request permission from the system, prompting the user with an authorization prompt or guidance screen. If the user rejects the request and selects 'Don’t ask again', the fail callback may be directly triggered. In this case, developers can invoke WVUIDialog.showAuthGuide to launch the system permission settings page and guide the user to manually enable the required permission for this App.