New Location Services Permissions Inconsistency

Question

question

Aardvark asked · Dec 14, 2018 at 02:42 PM

New Location Services Permissions Inconsistency

I am experimenting with the new Location Services feature that was announced yesterday. I have a SKill in development that already uses the country and postal code information so adding Location Services was easy. However, I have run into a problem checking for permissions due to an inconsistency in how permissions are validated. Previously, using examples posted by Amazon on GitHub, one would check for permissions as follows

const PERMISSIONS = ["alexa:device:all:address:country_and_postal_code:read"];
const accessToken = requestEnvelope.context.System.user.permissions &&
    requestEnvelope.context.System.apiAccessToken;
if (!accessToken) {
    return responseBuilder
        .speak("Please open the Alexa application and grant this Skill permission to access your location information.")
        .withAskForPermissionsConsentCard(PERMISSIONS)
        .getResponse();
}

However, with the new Location Services permission, this test no longer works. Now "requestEnvelope.context.System.user.permissions" is always defined if Location Services permission is requested by the Skill. Even if no permissions are granted by the user which in the past would cause the test in the code above to work. This is due to a new key of 'requestEnvelope.context.System.user.permissions.scopes["alexa::devices:all:geolocation:read"]' being defined with a property of "status". "status" is either "DENIED" or "GRANTED". This is all fine EXCEPT there is no corresponding key for the "read::alexa:device:all:address:country_and_postal_code" permission or possibly any other permission. So I have no reliable way to check for that permission being "GRANTED" or "DENIED". A simple check for the presence of "requestEnvelope.context.System.user.permissions" is no longer sufficient to determine whether or not "read::alexa:device:all:address:country_and_postal_code" is granted.

It would be nice to get some consistency in the permissions check behavior. Either provide the granted/denied status of all the requested permissions or go back to having permission undefined. Personally I prefer the former as knowing which permission may not have been granted is more helpful.

api permissions location services

0

10 |2000 characters needed characters left characters exceeded

Attachments: Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

3 Answers

Answer 1 · 2018-12-18T21:52:37Z

AaronG answered · Dec 18, 2018 at 09:52 PM · ACCEPTED ANSWER

Hi Aardvark,

The workaround you describe (call the API and catch a 403 FORBIDDEN response) is the current recommended mechanism, per https://developer.amazon.com/docs/custom-skills/device-address-api.html#permissions-card.

As you have learned, relying on the presence of the permissions object is ambiguous once your skill is configured for more than one permission scope. The consentToken object within the permissions object is considered deprecated in favor of the apiAccessToken (which is always present in the request, regardless of if the user has granted any permissions or not).

As you've also found, we currently only expose a limited number of permission scopes within the permissions object, and "alexa:device:all:address:country_and_postal_code:read" is not one of them. We're looking into expanding that list to include all relevant scopes, so that you would know beforehand if the country and postal code scope was accepted or denied. In the meantime, for permissions other than geolocation and autopay, we recommend continuing to invoke the skill and handle a 403 response as a normal part of a pre-consent workflow.

0 · Share

10 |2000 characters needed characters left characters exceeded

Attachments: Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Answer 2 · 2018-12-19T16:47:03Z

Aardvark answered · Dec 19, 2018 at 04:47 PM

Thanks for the information. I'm glad to see I chose the correct workaround. I hope that the "scopes" field is expanded eventually to support all permissions so that checking them will be easier. Right now I am doing something similar to this with Location Services permission:

const LOCATION_SERVICES_PERMISSION = ["alexa::devices:all:geolocation:read"];

const [permission] = LOCATION_SERVICES_PERMISSION;
if (!isPermissionGranted(handlerInput, permission)) {
    return responseBuilder
        .speak("Location Services permission is required to use this feature. Please enable it in the Alexa app.")
        .withAskForPermissionsConsentCard(LOCATION_SERVICES_PERMISSION)
        .getResponse();
}

/**
 * @param {Object} handlerInput Alexa handlerInput object
 * @param {String} permission Alexa Skill permission to check for
 * @returns {Boolean} true if permission is granted. false if it is not
 * @description checks to see if the desired Skill permission is granted
 */
function isPermissionGranted(handlerInput, permission) {
    const { requestEnvelope: { context: { System: { user } } } } = handlerInput;
    return user.permissions &&
        user.permissions.scopes &&
        user.permissions.scopes[permission] &&
        user.permissions.scopes[permission].status === "GRANTED";
}

It would be nice to do the same thing with "alexa:devices:all:address:country_and_postal_code:read" too (and the others as well). As I had some latency in retrieving the location and then doing a geolocation lookup, I have a progressive speech call to tell the user a location lookup operation is in progress.

In the past, I would not issue that progressive speech call if permission was lacking. Now I have to get part way into the lookup before I can issue the progressive speech call. Not a big issue but it would be great to have a preemptive permission lookup available with the 403 check as a fallback.

Robert

EDIT: A few moments ago I was testing the try/catch with the country and postal code lookup and I got an error. I was looking for the response type "FORBIDDEN". Come to find that sometime in the last 24 hours it is now returning "ACCESS_NOT_REQUESTED". So I will now check for a statusCode of 403 instead. It should be noted though that the documentation you referenced that says "403 Forbidden" is returned is now incorrect.

0 · Share

10 |2000 characters needed characters left characters exceeded

Attachments: Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Answer 3 · 2018-12-18T16:38:18Z

Aardvark answered · Dec 18, 2018 at 04:38 PM

Apparently this question has fallen by the wayside after four days. I did some further experimenting by enabling all possible permissions for my Skill and I found there are only two that use the new "scopes" property. The "geolocation" permission and the "autopay_consent" permission as shown in this JSON sent to my Skill in the test console:

"scopes": {
    "payments:autopay_consent": {
        "status": "DENIED"
    },
    "alexa::devices:all:geolocation:read": {
        "status": "GRANTED"
    }
}

All other permissions are not reflected in this property and there is no way I know of to check to see if they are enabled as the previous check for permission in various example code provided by Amazon does not work any longer. My solution for "alexa:device:all:address:country_and_postal_code:read" permission at the moment is to call the API within a try/catch block and if it fails with an error name of "ServiceError" and a response type of "FORBIDDEN" then I assume the permission is not enabled by the user and I send back a permission consent card. It works but it is not as reliable as being able to check the permission directly before making the API request.

0 · Share

10 |2000 characters needed characters left characters exceeded

Attachments: Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

New Location Services Permissions Inconsistency

question details

Related Questions