Previously, calling `$interval.cancel()` with a promise that was not
generated by a call to `$interval()` would do nothing. This could, for
example, happen when calling `.then()`/`.catch()` on the returned
promise, which creates a new promise, and passing that to
`$interval.cancel()`.
With this commit, `$interval.cancel()` will throw an error if called
with a non-$interval promise, thus surfacing errors that would otherwise
go unnoticed.
Related to #16424.
BREAKING CHNAGE:
`$interval.cancel()` will throw an error if called with a promise that
was not generated by `$interval()`. Previously, it would silently do
nothing.
Before:
```js
var promise = $interval(doSomething, 1000, 5).then(doSomethingElse);
$interval.cancel(promise); // No error; interval NOT canceled.
```
After:
```js
var promise = $interval(doSomething, 1000, 5).then(doSomethingElse);
$interval.cancel(promise); // Throws error.
```
Correct usage:
```js
var promise = $interval(doSomething, 1000, 5);
var newPromise = promise.then(doSomethingElse);
$interval.cancel(promise); // Interval canceled.
```
Closes#16476
Previously, calling `$timeout.cancel()` with a promise that was not
generated by a call to `$timeout()` would do nothing. This could, for
example, happen when calling `.then()`/`.catch()` on the returned
promise, which creates a new promise, and passing that to
`$timeout.cancel()`.
With this commit, `$timeout.cancel()` will throw an error if called with
a non-$timeout promise, thus surfacing errors that would otherwise go
unnoticed.
Fixes#16424
BREAKING CHNAGE:
`$timeout.cancel()` will throw an error if called with a promise that
was not generated by `$timeout()`. Previously, it would silently do
nothing.
Before:
```js
var promise = $timeout(doSomething, 1000).then(doSomethingElse);
$timeout.cancel(promise); // No error; timeout NOT canceled.
```
After:
```js
var promise = $timeout(doSomething, 1000).then(doSomethingElse);
$timeout.cancel(promise); // Throws error.
```
Correct usage:
```js
var promise = $timeout(doSomething, 1000);
var newPromise = promise.then(doSomethingElse);
$timeout.cancel(promise); // Timeout canceled.
```
BREAKING CHANGE
Previously the `tpload` error was namespaced to `$compile`. If you have
code that matches errors of the form `[$compile:tpload]` it will no
longer run. You should change the code to match
`[$templateRequest:tpload]`.
Thanks to @rjamet for the original work on this feature.
This is a large patch to handle URLs with the $sce service, similarly to HTML context.
Where we previously sanitized URL attributes when setting attribute value inside the
`$compile` service, we now only apply an `$sce` context requirement and leave the
`$interpolate` service to deal with sanitization.
This commit introduces a new `$sce` context called `MEDIA_URL`, which represents
a URL used as a source for a media element that is not expected to execute code, such as
image, video, audio, etc.
The context hierarchy is setup so that a value trusted as `URL` is also trusted in the
`MEDIA_URL` context, in the same way that the a value trusted as `RESOURCE_URL` is also
trusted in the `URL` context (and transitively also the `MEDIA_URL` context).
The `$sce` service will now automatically attempt to sanitize non-trusted values that
require the `URL` or `MEDIA_URL` context:
* When calling `getTrustedMediaUrl()` a value that is not already a trusted `MEDIA_URL`
will be sanitized using the `imgSrcSanitizationWhitelist`.
* When calling `getTrustedUrl()` a value that is not already a trusted `URL` will be
sanitized using the `aHrefSanitizationWhitelist`.
This results in behaviour that closely matches the previous sanitization behaviour.
To keep rough compatibility with existing apps, we need to allow concatenation of values
that may contain trusted contexts. The following approach is taken for situations that
require a `URL` or `MEDIA_URL` secure context:
* A single trusted value is trusted, e.g. `"{{trustedUrl}}"` and will not be sanitized.
* A single non-trusted value, e.g. `"{{ 'javascript:foo' }}"`, will be handled by
`getTrustedMediaUrl` or `getTrustedUrl)` and sanitized.
* Any concatenation of values (which may or may not be trusted) results in a
non-trusted type that will be handled by `getTrustedMediaUrl` or `getTrustedUrl` once the
concatenation is complete.
E.g. `"javascript:{{safeType}}"` is a concatenation of a non-trusted and a trusted value,
which will be sanitized as a whole after unwrapping the `safeType` value.
* An interpolation containing no expressions will still be handled by `getTrustedMediaUrl` or
`getTrustedUrl`, whereas before this would have been short-circuited in the `$interpolate`
service. E.g. `"some/hard/coded/url"`. This ensures that `ngHref` and similar directives
still securely, even if the URL is hard-coded into a template or index.html (perhaps by
server-side rendering).
BREAKING CHANGES:
If you use `attrs.$set` for URL attributes (a[href] and img[src]) there will no
longer be any automated sanitization of the value. This is in line with other
programmatic operations, such as writing to the innerHTML of an element.
If you are programmatically writing URL values to attributes from untrusted
input then you must sanitize it yourself. You could write your own sanitizer or copy
the private `$$sanitizeUri` service.
Note that values that have been passed through the `$interpolate` service within the
`URL` or `MEDIA_URL` will have already been sanitized, so you would not need to sanitize
these values again.
Previously the array entry for listeners was set to null but the array size was
not trimmed until the event was broadcasted again (see e6966e05f5).
By keeping track of the listener iteration index globally it can be adjusted if
a listener removal effects the index.
Fixes#16135Closes#16293
BREAKING CHANGE:
Recursively invoking `$emit` or `$broadcast` with the same event name is
no longer supported. This will now throw a `inevt` minErr.
- baddata error described incorrect http behavior, and workarounds
- httpProvider defaults were missing transformResponse / transformRequest
- http was not clear about JSON detection strategy
Closes#15897Closes#15906
Previously `$location` was rewriting such paths to remove not only the
double slashes but also the first segment of the path, leading to an invalid
path.
In this change, we deem leading double (back)slashes an invalid path and
now throw a `$location:badpath` error if that occurs.
Closes#15365
Closes#15157
BREAKING CHANGE:
`$http`'s deprecated custom callback methods - `success()` and `error()` - have been removed.
You can use the standard `then()`/`catch()` promise methods instead, but note that the method
signatures and return values are different.
`success(fn)` can be replaced with `then(fn)`, and `error(fn)` can be replaced with either
`then(null, fn)` or `catch(fn)`.
Before:
```js
$http(...).
success(function onSuccess(data, status, headers, config) {
// Handle success
...
}).
error(function onError(data, status, headers, config) {
// Handle error
...
});
```
After:
```js
$http(...).
then(function onSuccess(response) {
// Handle success
var data = response.data;
var status = response.status;
var statusText = response.statusText;
var headers = response.headers;
var config = response.config;
...
}, function onError(response) {
// Handle error
var data = response.data;
var status = response.status;
var statusText = response.statusText;
var headers = response.headers;
var config = response.config;
...
});
// or
$http(...).
then(function onSuccess(response) {
// Handle success
var data = response.data;
var status = response.status;
var statusText = response.statusText;
var headers = response.headers;
var config = response.config;
...
}).
catch(function onError(response) {
// Handle error
var data = response.data;
var status = response.status;
var statusText = response.statusText;
var headers = response.headers;
var config = response.config;
...
});
```
**Note:**
There is a subtle difference between the variations showed above. When using
`$http(...).success(onSuccess).error(onError)` or `$http(...).then(onSuccess, onError)`, the
`onError()` callback will only handle errors/rejections produced by the `$http()` call. If the
`onSuccess()` callback produces an error/rejection, it won't be handled by `onError()` and might go
unnoticed. In contrast, when using `$http(...).then(onSuccess).catch(onError)`, `onError()` will
handle errors/rejections produced by both `$http()` _and_ `onSuccess()`.
The query parameter that will be used to transmit the JSONP callback to the
server is now specified via the `jsonpCallbackParam` config value, instead of
using the `JSON_CALLBACK` placeholder.
* Any use of `JSON_CALLBACK` in a JSONP request URL will cause an error.
* Any request that provides a parameter with the same name as that given
by the `jsonpCallbackParam` config property will cause an error.
This is to prevent malicious attack via the response from an app inadvertently
allowing untrusted data to be used to generate the callback parameter.
Closes#15161Closes#15143Closes#11352Closes#11328
BREAKING CHANGE
You can no longer use the `JSON_CALLBACK` placeholder in your JSONP requests.
Instead you must provide the name of the query parameter that will pass the
callback via the `jsonpCallbackParam` property of the config object, or app-wide via
the `$http.defaults.jsonpCallbackParam` property, which is `"callback"` by default.
Before this change:
```
$http.json('trusted/url?callback=JSON_CALLBACK');
$http.json('other/trusted/url', {params:cb:'JSON_CALLBACK'});
```
After this change:
```
$http.json('trusted/url');
$http.json('other/trusted/url', {callbackParam:'cb'});
```
The $http service will reject JSONP requests that are not trusted by
`$sce` as "ResourceUrl".
This change makes is easier for developers to see clearly where in their
code they are making JSONP calls that may be to untrusted endpoings and
forces them to think about how these URLs are generated.
Be aware that this commit does not put any constraint on the parameters
that will be appended to the URL. Developers should be mindful of what
parameters can be attached and how they are generated.
Closes#11352
BREAKING CHANGE
All JSONP requests now require the URL to be trusted as resource URLs.
There are two approaches to trust a URL:
**Whitelisting with the `$sceDelegateProvider.resourceUrlWhitelist()`
method.**
You configure this list in a module configuration block:
```
appModule.config(['$sceDelegateProvider', function($sceDelegateProvider) {
$sceDelegateProvider.resourceUrlWhiteList([
// Allow same origin resource loads.
'self',
// Allow JSONP calls that match this pattern
'https://some.dataserver.com/**.jsonp?**`
]);
}]);
```
**Explicitly trusting the URL via the `$sce.trustAsResourceUrl(url)`
method**
You can pass a trusted object instead of a string as a URL to the `$http`
service:
```
var promise = $http.jsonp($sce.trustAsResourceUrl(url));
```
The angular expression parser (`$parse`) attempts to sandbox expressions
to prevent unrestricted access to the global context.
While the sandbox was not on the frontline of the security defense,
developers kept relying upon it as a security feature even though it was
always possible to access arbitrary JavaScript code if a malicious user
could control the content of Angular templates in applications.
This commit removes this sandbox, which has the following benefits:
* it sends a clear message to developers that they should not rely on
the sandbox to prevent XSS attacks; that they must prevent control of
expression and templates instead.
* it allows performance and size improvements in the core Angular 1
library.
* it simplifies maintenance and provides opportunities to make the
parser more capable.
Please see the [Sandbox Removal Blog Post](http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html)
for more detail on what you should do to ensure that your application is
secure.
Closes#15094
This allows the removal of try/catch from addDirective to avoid V8 deopt.
Previously the directive.restrict property was not validated. This would
potentially cause exceptions on each compilation of the directive
requiring a try/catch and potentially causing repeated errors.
New validation when directive.restrict is specified:
* must be a string
* must contain at least one valid character (E, A, C, M)
Cases which previously silently failed (now throw an error):
* values with an indexOf method (such as strings, arrays) which returned
returned -1 for all valid restrict characters
Cases which previously worked unintentionally (now throw an error):
* arrays with single-character strings of valid restrict characters
PR (#13263)
Previously the following would invoke the element link function multiple
times, causing unknown and potentially buggy results:
var link = $compile(html);
link(scope);
link(scope);
This was always unsupported. Now this throws a multilink error.
PR (#13422)
Previously, it would throw the ng:areq error, which is less
specific and just informs that the requested controller is not defined.
Given how commonly controllers are used
in Angular, it makes sense to have a specific error.
The ng:areq error is still thrown when the registered controller
is not a function.
Closes#14980
PR (#15015)
Thanks to @cironunes for the initial implementation in https://github.com/angular/angular.js/pull/9715
Adds support for binding to input[range] with the following behavior / features:
- Like input[number], it requires the model to be a Number, and will set the model to a Number
- it supports setting the min/max values via the min/max and ngMin/ngMax attributes
- it follows the browser behavior of never allowing an invalid value. That means, when the browser
converts an invalid value (empty: null, undefined, false ..., out of bounds: greater than max, less than min)
to a valid value, the input will in turn set the model to this new valid value via $setViewValue.
-- this means a range input will never be required and never have a non-Number model value, once the
ngModel directive is initialized.
-- this behavior is supported when the model changes and when the min/max attributes change in a way
that prompts the browser to update the input value.
-- ngMin / ngMax do not prompt the browser to update the values, as they don't set the attribute values.
Instead, they will set the min / max errors when appropriate
- browsers that do not support input[range] (IE9) handle the input like a number input (with validation etc.)
Closes#5892Closes#9715Close#14870
This change adds in the following new lifecycle hooks, which map in some
way to those in Angular 2:
* `$onChanges(changesObj)` - Called whenever one-way bindings are updated. The `changesObj` is a hash whose keys
are the names of the bound properties that have changed, and the values are an object of the form
`{ currentValue: ..., previousValue: ... }`. Use this hook to trigger updates within a component such as
cloning the bound value to prevent accidental mutation of the outer value.
* `$onDestroy` - Called on a controller when its containing scope is destroyed. Use this hook for releasing
external resources, watches and event handlers.
* `$postLink` - Called after this controller's element and its children been linked. Similar to the post-link
function this hook can be used to set up DOM event handlers and do direct DOM manipulation.
Note that child elements that contain `templateUrl` directives will not have been compiled and linked since
they are waiting for their template to load asynchronously and their own compilation and linking has been
suspended until that occurs.
Closes#14127Closes#14030Closes#14020Closes#13991Closes#14302
George Kalpakas
Pete Bacon Darwin
Jason Bedard
Martin Staffa
Zita Nemeckova
Jake Danforth
David Fuka
Martin Staffa
Joshua J Wilborn
Chirag Bhatia
Karthikeyan
emed
thorn0
Kevin Visscher
Michał Gołębiowski
Xavier Haniquaut
pmadruga
Huc Arnaud
Remy Sharp
Martin Sikora
Smith