Newer Version Available

This content describes an older version of this product. View Latest

Controlling Access

The framework enables you to control access to your applications, attributes, components, events, interfaces, and methods via the access system attribute. The access system attribute indicates whether the resource can be used outside of its own namespace.

Use the access system attribute on these tags:

  • <aura:application>
  • <aura:attribute>
  • <aura:component>
  • <aura:event>
  • <aura:interface>
  • <aura:method>

Access Values

You can specify these values for the access system attribute.

private
Available within the component, app, interface, or event and can’t be referenced externally. This value can only be used for aura:attribute.
public
Available within the same namespace. This is the default access value.
global
Available in all namespaces.

Mark your resources, such as a component, with access="global" to make the resource usable outside of your own org. For example, if you want a component to be usable in an installed package or by a Lightning App Builder user or a Community Builder user in another org.

Note

Example

This sample component has global access.

1<aura:component access="global">
2    ...
3</aura:component>

Access Violations

If your code accesses a resource, such as a component or attribute, that doesn’t have an access system attribute allowing you to access it, the code doesn’t execute or returns undefined. If you enabled debug mode, you also see an error message in your browser console. Access check enforcement is a critical update in this release. If you don’t update it, you continue to see warning messages in the browser console instead of errors.

Access check failures for <aura:event> and <aura:method> aren't enforced yet. If you've enabled debug mode, they show up as warnings in your browser console. The framework will enforce the <aura:event> and <aura:method> access checks more strictly in a later release so you shouldn’t ignore them.

Note

Anatomy of an Access Check Error Message

Here is a sample access check error message for an access violation.

1Access  Check  Failed ! ComponentService.getDef():'markup://c:targetComponent' is not visible to 'markup://c:sourceComponent'.

An error message has four parts:

  1. The context (who is trying to access the resource). In our example, this is markup://c:sourceComponent.
  2. The target (the resource being accessed). In our example, this is markup://c:targetComponent.
  3. The type of failure. In our example, this is not visible.
  4. The code that triggered the failure. This is usually a class method. In our example, this is ComponentService.getDef(), which means that the target definition (component) was not accessible. A definition describes metadata for a resource, such as a component.

Fixing Access Check Errors

You can fix access check errors using one or more of these techniques.

  • Add appropriate access system attributes to the resources that you own.
  • Remove references in your code to resources that aren’t available. In the earlier example, markup://c:targetComponent doesn't have an access value allowing markup://c:sourceComponent to access it.
  • Ensure that any attribute that you’re accessing exists by looking at its <aura:attribute> definition. Confirm that you’re using the correct case-sensitive spelling for the name.

    Accessing an undefined attribute or an attribute that is out of scope, for example a private attribute, triggers the same access violation message. The access context doesn’t know whether the attribute is undefined or inaccessible.

Example: is not visible to 'undefined'

1ComponentService.getDef():'markup://c:targetComponent' is not visible to 'undefined'

The key word in this error message is undefined, which indicates that the framework has lost context. This happens when your code accesses a component outside the normal framework lifecycle, such as in a setTimeout() or setInterval() call or in an ES6 Promise.

Fix this error by wrapping the code in a $A.getCallback() call. For more information, see Modifying Components Outside the Framework Lifecycle.

Example: is not visible to 'InvalidComponent ...'

1ComponentService.getDef():'markup://c:targetComponent' is not visible to 'InvalidComponent markup://c:sourceComponent'

The key word in this error message is InvalidComponent, which indicates that c:sourceComponent is invalid and has been destroyed.

Always add an isValid() check if you reference a component in asynchronous code, such as a callback or a timeout. If you navigate elsewhere in the UI while asynchronous code is executing, the framework unrenders and destroys the component that made the asynchronous request. You can still have a reference to that component, but it is no longer valid. Add an isValid() call to check that the component is still valid before processing the results of the asynchronous request.

Activate the Critical Update

We recommend that you test this update in a sandbox or Developer Edition org to verify correct behavior before enabling it in your production org.

To activate this critical update:

  1. From Setup, enter Critical Updates in the Quick Find box, and then select Critical Updates.
  2. For “Enforce Lightning Components Access Checks”, click Activate.