Lightning Components Developer's Guide

Introducing the Lightning Component Framework
Quick Start
Creating Components
Working with UI Components
Using Expressions
Supporting Accessibility
Communicating with Events
Creating Apps
App Overview
Designing App UI
Creating App Templates
Content Security Policy Overview
Styling Apps
Using JavaScript
JavaScript Cookbook
Using Apex
Using Object-Oriented Development
Using the AppCache
Controlling Access
Application Access Control
Interface Access Control
Component Access Control
Attribute Access Control
Event Access Control
Distributing Applications and Components
Debugging
Reference
PDF

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, interfaces, components, attributes, and events via the access system attribute on the aura:application, aura:interface, aura:component, aura:attribute, and aura:event tags. The access system attribute indicates whether the resource can be used outside of its own namespace.

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.

Setting access="global" makes a bundle available to package subscribers and other namespaces. For more information on packaging, see Distributing Applications and Components

As access checks will be more strictly enforced in a later release, mark your resources with access="global" now to make the resource usable outside of your own org; for example, if you want the resource to be usable in an installed package or by a Lightning App Builder user or a Community Builder user in another org.

Note

Anatomy of an Access Check Warning

If you access a resource, such as a component or attribute, that doesn’t have an access system attribute allowing you to access it, you’ll see a warning in your browser console. The framework will enforce these access checks more strictly in the future so you shouldn’t ignore them.

This is a sample access check warning message.

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

A warning message has four parts:

  1. The context (who is trying to access the resource). In our example, this is undefined.
  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 Warnings

Fix any access check warnings 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 are not available
  • Ensure that any attribute that you’re accessing exists and that you’re using the correct spelling. Undefined attributes trigger the same access violation as accessing a private attribute. The message is the same because the access context doesn’t know whether the attribute exists or is undefined.
  • Use $A.getCallback() to wrap any code that accesses a component outside the normal rerendering lifecycle, such as in a setTimeout() or setInterval() call or in an ES6 Promise. $A.getCallback() preserves the current execution context and grants the correct access level to the asynchronous code. Otherwise, the framework loses context and only allows access to global resources.