From 4ab16aaaf762e9038803da1f967ac8cb6650727d Mon Sep 17 00:00:00 2001 From: Vojta Jina Date: Wed, 13 Nov 2013 23:25:09 -0800 Subject: feat($parse): revert hiding "private" properties Hiding `_*` properties was a feature primarily for developers using Closure compiler and Google JS style. We didn't realize how many people will be affected by this change. We might introduce this feature in the future, probably under a config option, but it needs more research and so I'm reverting the change for now. This reverts commit 3d6a89e8888b14ae5cb5640464e12b7811853c7e. Closes #4926 Closes #4842 Closes #4865 Closes #4859 Closes #4849 Conflicts: src/ng/parse.js --- docs/content/error/parse/isecprv.ngdoc | 50 ---------------------------------- 1 file changed, 50 deletions(-) delete mode 100644 docs/content/error/parse/isecprv.ngdoc (limited to 'docs/content/error') diff --git a/docs/content/error/parse/isecprv.ngdoc b/docs/content/error/parse/isecprv.ngdoc deleted file mode 100644 index 4bb02426..00000000 --- a/docs/content/error/parse/isecprv.ngdoc +++ /dev/null @@ -1,50 +0,0 @@ -@ngdoc error -@name $parse:isecprv -@fullName Referencing private Field in Expression - -@description - -Occurs when an Angular expression attempts to access a private field. - -Fields with names that begin or end with an underscore are considered -private fields.  Angular expressions are not allowed to reference such -fields on the scope chain.  This only applies to Angular expressions -(e.g. {{ }} interpolation and calls to `$parse` with a string expression -argument) – Javascript itself has no such notion. - -To resolve this error, use an alternate non-private field if available -or make the field public (by removing any leading and trailing -underscore characters from its name.) - -Example expression that would result in this error: - -```html -
{{user._private_field}}
-``` - -Background: -Though Angular expressions are written and controlled by the developer -and are trusted, they do represent an attack surface due to the -following two factors: - -- they typically deal with user input which is generally high risk -- they often don't get the kind of attention and test coverage that - JavaScript code would. - -If these expression were evaluated in a context with full trust, an -attacker, though unable to change the expression itself, can feed it -unexpected and dangerous input that could result in a security -breach/exploit. - -As such, Angular expressions are evaluated in a limited context.  They -do not have direct access to the global scope, Window, Document, the -Function constructor or "private" properties (names beginning or ending -with an underscore character) on the scope chain.  They should get their -work done via public properties and methods exposed on the scope chain -(keep in mind that this includes controllers as well as they are -published on the scope via the "controller as" syntax.) - -As a best practise, only "publish" properties on the scopes and -controllers that must be available to Angular expressions.  All other -members should either be in closures or be "private" by giving them -names with a leading or trailing underscore character. -- cgit v1.2.3