| Age | Commit message (Collapse) | Author | 
|---|
|  | Closed #6544. | 
|  | These errors in the docs were preventing some parts of the docs from being
parsed. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | protractor
Thanks to jeffbcross, petebacondarwin, btford, jdeboer, tbosch for contributions!
Closes #6023 | 
|  | The "size" attribute gets set on <font> elements when using HTML5 rich
text editors, or elements with the contenteditable attribute, that rely
on the 'fontSize' command (execCommand).
Closes #5522 | 
|  | innerText depends on styling as it doesn't display hidden elements.
Therefore, it's better to use textContent not to cause unnecessary
reflows. However, IE<9 don't support textContent so the innerText
fallback is necessary. | 
|  | In Safari 7 (and other browsers potentially using the latest YARR JIT library)
regular expressions are not always executed immediately that they are called.
The regex is only evaluated (lazily) when you first access properties on the `matches`
result object returned from the regex call.
In the case of `decodeEntities()`, we were updating this returned object, `parts[0] = ''`,
before accessing it, `if (parts[2])', and so our change was overwritten by the result
of executing the regex.
The solution here is not to modify the match result object at all. We only need to make use
of the three match results directly in code.
Developers should be aware, in the future, when using regex, to read from the result object
before making modifications to it.
There is no additional test committed here, because when run against Safari 7, this
bug caused numerous specs to fail, which are all fixed by this commit.
Closes #5193
Closes #5192 | 
|  | `$sanitize` now uses the same mechanism as `$compile` to validate uris.
By this, the validation in `$sanitize` is more general and can be
configured in the same way as the one in `$compile`.
Changes
- Creates the new private service `$$sanitizeUri`.
- Moves related specs from `compileSpec.js` into `sanitizeUriSpec.js`.
- Refactors the `linky` filter to be less dependent on `$sanitize`
  internal functions.
Fixes #3748. | 
|  |  | 
|  |  | 
|  | HTML to be sanitized that contains a DOCTYPE declaration were causing
the HTML parser to throw an error.  Now the parser correctly removes
the declarations when sanitizing HTML.
Closes #3931 | 
|  | According to http://validator.w3.org/ , <!--> is not a valid comment
and neither is any comment containing the -- substring. | 
|  | Currently, the documentation does a bad job of explaining the distinction between the services that it provides,
and the module itself. Furthermore, the instructions for using optional modules are inconsistent or missing.
This commit addresses the problem by ading a new `{@installModule foo}` annotation to the docs generator that
inlines the appropriate instructions based on the name of the module. | 
|  | Closes #3527 | 
|  | Changes:
- remove ng-bind-html-unsafe
- ng-bind-html is now in core
- ng-bind-html is secure
  - supports SCE - so you can bind to an arbitrary trusted string
  - automatic sanitization if $sanitize is available
BREAKING CHANGE:
  ng-html-bind-unsafe has been removed and replaced by ng-html-bind
  (which has been removed from ngSanitize.)  ng-bind-html provides
  ng-html-bind-unsafe like behavior (innerHTML's the result without
  sanitization) when bound to the result of $sce.trustAsHtml(string).
  When bound to a plain string, the string is sanitized via $sanitize
  before being innerHTML'd.  If $sanitize isn't available, it's logs an
  exception. | 
|  | $sce is a service that provides Strict Contextual Escaping services to AngularJS.
Strict Contextual Escaping
--------------------------
Strict Contextual Escaping (SCE) is a mode in which AngularJS requires
bindings in certain contexts to result in a value that is marked as safe
to use for that context One example of such a context is binding
arbitrary html controlled by the user via ng-bind-html-unsafe.  We
refer to these contexts as privileged or SCE contexts.
As of version 1.2, Angular ships with SCE enabled by default.
Note:  When enabled (the default), IE8 in quirks mode is not supported.
In this mode, IE8 allows one to execute arbitrary javascript by the use
of the expression() syntax.  Refer
http://blogs.msdn.com/b/ie/archive/2008/10/16/ending-expressions.aspx
to learn more about them.  You can ensure your document is in standards
mode and not quirks mode by adding <!doctype html> to the top of your
HTML document.
SCE assists in writing code in way that (a) is secure by default and (b)
makes auditing for security vulnerabilities such as XSS, clickjacking,
etc. a lot easier.
Here's an example of a binding in a privileged context:
  <input ng-model="userHtml">
  <div ng-bind-html-unsafe="{{userHtml}}">
Notice that ng-bind-html-unsafe is bound to {{userHtml}} controlled by
the user.  With SCE disabled, this application allows the user to render
arbitrary HTML into the DIV.  In a more realistic example, one may be
rendering user comments, blog articles, etc. via bindings.  (HTML is
just one example of a context where rendering user controlled input
creates security vulnerabilities.)
For the case of HTML, you might use a library, either on the client side, or on the server side,
to sanitize unsafe HTML before binding to the value and rendering it in the document.
How would you ensure that every place that used these types of bindings was bound to a value that
was sanitized by your library (or returned as safe for rendering by your server?)  How can you
ensure that you didn't accidentally delete the line that sanitized the value, or renamed some
properties/fields and forgot to update the binding to the sanitized value?
To be secure by default, you want to ensure that any such bindings are disallowed unless you can
determine that something explicitly says it's safe to use a value for binding in that
context.  You can then audit your code (a simple grep would do) to ensure that this is only done
for those values that you can easily tell are safe - because they were received from your server,
sanitized by your library, etc.  You can organize your codebase to help with this - perhaps
allowing only the files in a specific directory to do this.  Ensuring that the internal API
exposed by that code doesn't markup arbitrary values as safe then becomes a more manageable task.
In the case of AngularJS' SCE service, one uses $sce.trustAs (and
shorthand methods such as $sce.trustAsHtml, etc.) to obtain values that
will be accepted by SCE / privileged contexts.
In privileged contexts, directives and code will bind to the result of
$sce.getTrusted(context, value) rather than to the value directly.
Directives use $sce.parseAs rather than $parse to watch attribute
bindings, which performs the $sce.getTrusted behind the scenes on
non-constant literals.
As an example, ngBindHtmlUnsafe uses $sce.parseAsHtml(binding
expression).  Here's the actual code (slightly simplified):
  var ngBindHtmlUnsafeDirective = ['$sce', function($sce) {
    return function(scope, element, attr) {
      scope.$watch($sce.parseAsHtml(attr.ngBindHtmlUnsafe), function(value) {
        element.html(value || '');
      });
    };
  }];
Impact on loading templates
---------------------------
This applies both to the ng-include directive as well as templateUrl's
specified by directives.
By default, Angular only loads templates from the same domain and
protocol as the application document.  This is done by calling
$sce.getTrustedResourceUrl on the template URL.  To load templates from
other domains and/or protocols, you may either either whitelist them or
wrap it into a trusted value.
*Please note*:
The browser's Same Origin Policy and Cross-Origin Resource Sharing
(CORS) policy apply in addition to this and may further restrict whether
the template is successfully loaded.  This means that without the right
CORS policy, loading templates from a different domain won't work on all
browsers.  Also, loading templates from file:// URL does not work on
some browsers.
This feels like too much overhead for the developer?
----------------------------------------------------
It's important to remember that SCE only applies to interpolation expressions.
If your expressions are constant literals, they're automatically trusted
and you don't need to call $sce.trustAs on them.
e.g.  <div ng-html-bind-unsafe="'<b>implicitly trusted</b>'"></div> just works.
Additionally, a[href] and img[src] automatically sanitize their URLs and
do not pass them through $sce.getTrusted.  SCE doesn't play a role here.
The included $sceDelegate comes with sane defaults to allow you to load
templates in ng-include from your application's domain without having to
even know about SCE.  It blocks loading templates from other domains or
loading templates over http from an https served document.  You can
change these by setting your own custom whitelists and blacklists for
matching such URLs.
This significantly reduces the overhead.  It is far easier to pay the
small overhead and have an application that's secure and can be audited
to verify that with much more ease than bolting security onto an
application later. | 
|  | This allows us to use minErr in other modules, such as resource and sanitize. | 
|  |  | 
|  | According to RFC 3986 (http://tools.ietf.org/html/rfc3986#section-3.1)
schemes such as http or mailto are case-insensitive. So links such as
http://server/ and HTTP://server/ are valid and equivalent.
Closes #3210 | 
|  |  | 
|  |  | 
|  | Per http://www.ietf.org/rfc/rfc3966.txt support tel: links | 
|  | we now have two types of namespaces:
- true namespace: angular.* - used for all global apis
- virtual namespace: ng.*, ngMock.*, ... - used for all DI modules
the virual namespaces have services under the second namespace level (e.g. ng.)
and filters and directives prefixed with filter: and directive: respectively
(e.g. ng.filter:orderBy, ng.directive:ngRepeat)
this simplifies urls and makes them a lot shorter while still avoiding name collisions | 
|  | Create build for other modules as well (ngResource, ngCookies):
- wrap into a function
- add license
- add version
Breaks `$sanitize` service, `ngBindHtml` directive and `linky` filter were moved to the `ngSanitize` module. Apps that depend on any of these will need to load `angular-sanitize.js` and include `ngSanitize` in their dependency list: `var myApp = angular.module('myApp', ['ngSanitize']);` |