Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update dependency angular to v1.8.0 #125

Open
wants to merge 1 commit into
base: v2
Choose a base branch
from
Open

Update dependency angular to v1.8.0 #125

wants to merge 1 commit into from

Conversation

mend-for-github-com[bot]
Copy link

@mend-for-github-com mend-for-github-com bot commented Oct 9, 2020 •
edited
Loading

This PR contains the following updates:

Package Type Update Change
angular (source) devDependencies minor 1.2.30 -> 1.8.0

By merging this PR, the below issues will be automatically resolved and closed:

Severity CVSS Score CVE GitHub Issue
Medium 6.1 CVE-2019-14863 #81
Medium 5.8 WS-2017-0116 #82
Medium 5.8 WS-2017-0118 #84
Medium 4.8 WS-2017-0122 #86
Medium 5.3 WS-2017-0124 #87
Medium 6.1 WS-2018-0001 #89
Medium 5.5 WS-2018-0002 #90
Medium 6.1 WS-2018-0022 #91
Medium 5.4 CVE-2020-7676 #111

Release Notes

angular/angular.js

v1.8.0

Compare Source

This release contains a breaking change to resolve a security issue which was discovered by
Krzysztof Kotowicz(@​koto); and independently by Esben Sparre Andreasen (@​esbena) while
performing a Variant Analysis of CVE-2020-11022
which itself was found and reported by Masato Kinugawa (@​masatokinugawa).

Bug Fixes

  • jqLite:
    • prevent possible XSS due to regex-based HTML replacement
      (2df43c)

Breaking Changes

jqLite due to:
  • 2df43c: prevent possible XSS due to regex-based HTML replacement

JqLite no longer turns XHTML-like strings like <div /><span /> to sibling elements <div></div><span></span>
when not in XHTML mode. Instead it will leave them as-is. The browser, in non-XHTML mode, will convert these to:
<div><span></span></div>.

This is a security fix to avoid an XSS vulnerability if a new jqLite element is created from a user-controlled HTML string.
If you must have this functionality and understand the risk involved then it is posible to restore the original behavior by calling

angular.UNSAFE_restoreLegacyJqLiteXHTMLReplacement();

But you should adjust your code for this change and remove your use of this function as soon as possible.

Note that this only patches jqLite. If you use jQuery 3.5.0 or newer, please read the jQuery 3.5 upgrade guide for more details about the workarounds.

v1.7.9

Compare Source

Bug Fixes

v1.7.8

Compare Source

Bug Fixes

v1.7.7

Compare Source

Bug Fixes

v1.7.6

Compare Source

Bug Fixes

Performance Improvements

v1.7.5

Compare Source

Bug Fixes

v1.7.4

Compare Source

Bug Fixes

v1.7.3

Compare Source

Bug Fixes

New Features

Performance Improvements

v1.7.2

Compare Source

In the previous release, we removed a private, undocumented API that was no longer used by
AngularJS. It turned out that several popular UI libraries (such as
AngularJS Material,
UI Bootstrap,
ngDialog and probably others) relied on that API.

In order to avoid unnecessary pain for developers, this release reverts the removal of the private
API and restores compatibility of the aforementioned libraries with the latest AngularJS.

Reverts

v1.7.1

Compare Source

Bug Fixes

New Features

v1.7.0

Compare Source

Here are the full changes for the release of 1.7.0 that are not already released in the 1.6.x branch,
which includes commits from 1.7.0-rc.0 and commits from 1.7.0 directly.

1.7.0 is the last scheduled release of AngularJS that includes breaking changes. 1.7.x patch
releases will continue to receive bug fixes and non-breaking features until AngularJS enters Long
Term Support mode (LTS) on July 1st 2018.

Bug Fixes

New Features

Performance Improvements

  • $rootScope: allow $watchCollection use of expression input watching
    (97b00c)
  • ngStyle: use $watchCollection
    (15bbd3,
    #​15947)
  • $compile: do not use deepWatch in literal one-way bindings
    (fd4f01,
    #​15301)

Breaking Changes

jqLite due to:
  • b7d396: make removeData() not remove event handlers

Before this commit removeData() invoked on an element removed its event
handlers as well. If you want to trigger a full cleanup of an element, change:

elem.removeData();

to:

angular.element.cleanData(elem);

In most cases, though, cleaning up after an element is supposed to be done
only when it's removed from the DOM as well; in such cases the following:

elem.remove();

will remove event handlers as well.

$cookies due to:
  • 73c646: remove the deprecated $cookieStore factory

The $cookieStore has been removed. Migrate to the $cookies service. Note that
for object values you need to use the putObject & getObject methods as
get/put will not correctly save/retrieve them.

Before:

$cookieStore.put('name', {key: 'value'});
$cookieStore.get('name'); // {key: 'value'}
$cookieStore.remove('name');

After:

$cookies.putObject('name', {key: 'value'});
$cookies.getObject('name'); // {key: 'value'}
$cookies.remove('name');
$resource due to:
  • ea0585: fix interceptors and success/error callbacks

If you are not using success or error callbacks with $resource,
your app should not be affected by this change.

If you are using success or error callbacks (with or without
response interceptors), one (subtle) difference is that throwing an
error inside the callbacks will not propagate to the returned
$promise. Therefore, you should try to use the promises whenever
possible. E.g.:

// Avoid
User.query(function onSuccess(users) { throw new Error(); }).
  $promise.
  catch(function onError() { /* Will not be called. */ });

// Prefer
User.query().
  $promise.
  then(function onSuccess(users) { throw new Error(); }).
  catch(function onError() { /* Will be called. */ });

Finally, if you are using success or error callbacks with response
interceptors, the callbacks will now always run after the interceptors
(and wait for them to resolve in case they return a promise).
Previously, the error callback was called before the responseError
interceptor and the success callback was synchronously called after
the response interceptor. E.g.:

var User = $resource('/api/users/:id', {id: '@&#8203;id'}, {
  get: {
    method: 'get',
    interceptor: {
      response: function(response) {
        console.log('responseInterceptor-1');
        return $timeout(1000).then(function() {
          console.log('responseInterceptor-2');
          return response.resource;
        });
      },
      responseError: function(response) {
        console.log('responseErrorInterceptor-1');
        return $timeout(1000).then(function() {
          console.log('responseErrorInterceptor-2');
          return $q.reject('Ooops!');
        });
      }
    }
  }
});
var onSuccess = function(value) { console.log('successCallback', value); };
var onError = function(error) { console.log('errorCallback', error); };

// Assuming the following call is successful...
User.get({id: 1}, onSuccess, onError);
  // Old behavior:
  //   responseInterceptor-1
  //   successCallback, {/* Promise object */}
  //   responseInterceptor-2
  // New behavior:
  //   responseInterceptor-1
  //   responseInterceptor-2
  //   successCallback, {/* User object */}

// Assuming the following call returns an error...
User.get({id: 2}, onSuccess, onError);
  // Old behavior:
  //   errorCallback, {/* Response object */}
  //   responseErrorInterceptor-1
  //   responseErrorInterceptor-2
  // New behavior:
  //   responseErrorInterceptor-1
  //   responseErrorInterceptor-2
  //   errorCallback, Ooops!
  • 240a3d: add support for request and requestError interceptors (#​15674)

Previously, calling a $resource method would synchronously call
$http. Now, it will be called asynchronously (regardless if a
request/requestError interceptor has been defined.

This is not expected to affect applications at runtime, since the
overall operation is asynchronous already, but may affect assertions in
tests. For example, if you want to assert that $http has been called
with specific arguments as a result of a $resource call, you now need
to run a $digest first, to ensure the (possibly empty) request
interceptor promise has been resolved.

Before:

it('...', function() {
  $httpBackend.expectGET('/api/things').respond(...);
  var Things = $resource('/api/things');
  Things.query();

  expect($http).toHaveBeenCalledWith(...);
});

After:

it('...', function() {
  $httpBackend.expectGET('/api/things').respond(...);
  var Things = $resource('/api/things');
  Things.query();
  $rootScope.$digest();

  expect($http).toHaveBeenCalledWith(...);
});
$templateRequest:
  • due to c617d6: give tpload error the correct namespace

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].

  • due to (fb0099: always return the template that is stored in the cache

The service now returns the result of $templateCache.put() when making a server request to the
template. Previously it would return the content of the response directly.
This now means if you are decorating $templateCache.put() to manipulate the template, you will
now get this manipulated result also on the first $templateRequest rather than only on subsequent
calls (when the template is retrived from the cache).
In practice this should not affect any apps, as it is unlikely that they rely on the template being
different in the first and subsequent calls.

$animate due to:
  • 16b82c: let cancel() reject the runner promise

$animate.cancel(runner) now rejects the underlying
promise and calls the catch() handler on the runner
returned by $animate functions (enter, leave, move,
addClass, removeClass, setClass, animate).
Previously it would resolve the promise as if the animation
had ended successfully.

Example:

var runner = $animate.addClass('red');
runner.then(function() { console.log('success')});
runner.catch(function() { console.log('cancelled')});

runner.cancel();

Pre-1.7.0, this logs 'success', 1.7.0 and later it logs 'cancelled'.
To migrate, add a catch() handler to your animation runners.

angular.isArray due to:
  • e3ece2: support Array subclasses in angular.isArray()

Previously, angular.isArray() was an alias for Array.isArray().
Therefore, objects that prototypally inherit from Array where not
considered arrays. Now such objects are considered arrays too.

This change affects several other methods that use angular.isArray()
under the hood, such as angular.copy(), angular.equals(),
angular.forEach(), and angular.merge().

This in turn affects how dirty checking treats objects that prototypally
inherit from Array (e.g. MobX observable arrays). AngularJS will now
be able to handle these objects better when copying or watching.

$sce :
  • due to 1e9ead: handle URL sanitization through the $sce service

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.

  • due to 1e9ead: handle URL sanitization through the $sce service

binding trustAs() and the short versions (trustAsResourceUrl() et al.) to
ngSrc, ngSrcset, and ngHref will now raise an infinite digest error:

  $scope.imgThumbFn = function(id) {
    return $sce.trustAsResourceUrl(someService.someUrl(id));
  };
  <img ng-src="{{imgThumbFn(imgId)}}">

This is because the $interpolate service is now responsible for sanitizing
the attribute value, and its watcher receives a new object from trustAs()
on every digest.
To migrate, compute the trusted value only when the input value changes:

  $scope.$watch('imgId', function(id) {
    $scope.imgThumb = $sce.trustAsResourceUrl(someService.someUrl(id));
  });
  <img ng-src="{{imgThumb}}">
orderBy due to:
  • 1d8046: consider null and undefined greater than other values

When using orderBy to sort arrays containing null values, the null values
will be considered "greater than" all other values, except for undefined.
Previously, they were sorted as strings. This will result in different (but more
intuitive) sorting order.

Before:

orderByFilter(['a', undefined, 'o', null, 'z']);
//--> 'a', null, 'o', 'z', undefined

After:

orderByFilter(['a', undefined, 'o', null, 'z']);
//--> 'a', 'o', 'z', null, undefined
ngScenario due to:
  • 0cd392: completely remove the angular scenario runner

The angular scenario runner end-to-end test framework has been
removed from the project and will no longer be available on npm
or bower starting with 1.7.0.
It was deprecated and removed from the documentation in 2014.
Applications that still use it should migrate to
Protractor.
Technically, it should also be possible to continue using an
older version of the scenario runner, as the underlying APIs have
not changed. However, we do not guarantee future compatibility.

form due to:
  • 223de5: set $submitted to true on child forms when parent is submitted

Forms will now set $submitted on child forms when they are submitted.
For example:

<form name="parentform" ng-submit="$ctrl.submit()">
  <ng-form name="childform">
    <input type="text" name="input" ng-model="my.model" />
  </ng-form>
  <input type="submit" />
</form>

Submitting this form will set $submitted on "parentform" and "childform".
Previously, it was only set on "parentform".

This change was introduced because mixing form and ngForm does not create
logically separate forms, but rather something like input groups.
Therefore, child forms should inherit the submission state from their parent form.

ngAria due to:
  • 6d5ef3: do not set aria attributes on input[type="hidden"]

ngAria no longer sets aria-* attributes on input[type="hidden"] with ngModel.
This can affect apps that test for the presence of aria attributes on hidden inputs.
To migrate, remove these assertions.
In actual apps, this should not have a user-facing effect, as the previous behavior
was incorrect, and the new behavior is correct for accessibility.

ngModel, input due to:
  • 74b04c: improve handling of built-in named parsers

Custom parsers that fail to parse on input types "email", "url", "number", "date", "month",
"time", "datetime-local", "week", do no longer set ngModelController.$error[inputType], and
the ng-invalid-[inputType] class. Also, custom parsers on input type "range" do no
longer set ngModelController.$error.number and the ng-invalid-number class.

Instead, any custom parsers on these inputs set ngModelController.$error.parse and
ng-invalid-parse. This change was made to make distinguishing errors from built-in parsers
and custom parsers easier.

ngModelOptions due to:
  • 55ba44: add debounce catch-all + allow debouncing 'default' only

the 'default' key in 'debounce' now only debounces the default event, i.e. the event
that is added as an update trigger by the different input directives automatically.

Previously, it also applied to other update triggers defined in 'updateOn' that
did not have a corresponding key in the 'debounce'.

This behavior is now supported via a special wildcard / catch-all key: '*'.

See the following example:

Pre-1.7:
'mouseup' is also debounced by 500 milliseconds because 'default' is applied:

ng-model-options="{
  updateOn: 'default blur mouseup',
  debounce: { 'default': 500, 'blur': 0 }
}

1.7:
The pre-1.7 behavior can be re-created by setting '*' as a catch-all debounce value:

ng-model-options="{
  updateOn: 'default blur mouseup',
  debounce: { '*': 500, 'blur': 0 }
}

In contrast, when only 'default' is used, 'blur' and 'mouseup' are not debounced:

ng-model-options="{
  updateOn: 'default blur mouseup',
  debounce: { 'default': 500 }
}
input[number] due to:
  • aa3f95: validate min/max against viewValue

input[type=number] with ngModel now validates the input for the max/min restriction against
the ngModelController.$viewValue instead of against the ngModelController.$modelValue.

This affects apps that use $parsers or $formatters to transform the input / model value.

If you rely on the $modelValue validation, you can overwrite the min/max validator from a custom directive, as seen in the following example directive definition object:

{
  restrict: 'A',
  require: 'ngModel',
  link: function(scope, element, attrs, ctrl) {
    var maxValidator = ctrl.$validators.max;

    ctrl.$validators.max = function(modelValue, viewValue) {
      return maxValidator(modelValue, modelValue);
    };
  }
}
input due to:
  • 656c8f: listen on "change" instead of "click" for radio/checkbox ngModels

input[radio] and input[checkbox] now listen to the "change" event instead of the "click" event.
Most apps should not be affected, as "change" is automatically fired by browsers after "click"
happens.

Two scenarios might need migration:

  • Custom click events:

Before this change, custom click event listeners on radio / checkbox would be called after the
input element and ngModel had been updated, unless they were specifically registered before
the built-in click handlers.
After this change, they are called before the input is updated, and can call event.preventDefault()
to prevent the input from updating.

If an app uses a click event listener that expects ngModel to be updated when it is called, it now
needs to register a change event listener instead.

  • Triggering click events:

Conventional trigger functions:

The change event might not be fired when the input element is not attached to the document. This
can happen in tests that compile input elements and
trigger click events on them. Depending on the browser (Chrome and Safari) and the trigger method,
the change event will not be fired when the input isn't attached to the document.

Before:

    it('should update the model', inject(function($compile, $rootScope) {
      var inputElm = $compile('<input type="checkbox" ng-model="checkbox" />')($rootScope);

      inputElm[0].click(); // Or different trigger mechanisms, such as jQuery.trigger()
      expect($rootScope.checkbox).toBe(true);
    });

With this patch, $rootScope.checkbox might not be true, because the click event
hasn't triggered the change event. To make the test, work append the inputElm to the app's
$rootElement, and the $rootElement to the $document.

After:

    it('should update the model', inject(function($compile, $rootScope, $rootElement, $document) {
      var inputElm = $compile('<input type="checkbox" ng-model="checkbox" />')($rootScope);

      $rootElement.append(inputElm);
      $document.append($rootElement);

      inputElm[0].click(); // Or different trigger mechanisms, such as jQuery.trigger()
      expect($rootScope.checkbox).toBe(true);
    });

triggerHandler():

If you are using this jQuery / jqLite function on the input elements, you don't have to attach
the elements to the document, but instead change the triggered event to "change". This is because
triggerHandler(event) only triggers the exact event when it has been added by jQuery / jqLite.

ngStyle due to:
  • 15bbd3: use $watchCollection

Previously the use of deep watch by ng-style would trigger styles to be
re-applied when nested state changed. Now only changes to direct
properties of the watched object will trigger changes.

$compile due to:
  • 38f8c9: remove the preAssignBindingsEnabled flag

Previously, the $compileProvider.preAssignBindingsEnabled flag was supported.
The flag controlled whether bindings were available inside the controller
constructor or only in the $onInit hook. The bindings are now no longer
available in the constructor.

To migrate your code:

  1. If you haven't invoked $compileProvider.preAssignBindingsEnabled() you
    don't have to do anything to migrate.

  2. If you specified $compileProvider.preAssignBindingsEnabled(false), you
    can remove that statement - since AngularJS 1.6.0 this is the default so your
    app should still work even in AngularJS 1.6 after such removal. Afterwards,
    migrating to AngularJS 1.7.0 shouldn't require any further action.

  3. If you specified $compileProvider.preAssignBindingsEnabled(true) you need
    to first migrate your code so that the flag can be flipped to false. The
    instructions on how to do that are available in the "Migrating from 1.5 to 1.6"
    guide:
    https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6
    Afterwards, remove the $compileProvider.preAssignBindingsEnabled(true)
    statement.

  • 6ccbfa: lower the xlink:href security context for SVG's a and image elements

In the unlikely case that an app relied on RESOURCE_URL whitelisting for the
purpose of binding to the xlink:href property of SVG's <a> or <image>
elements and if the values do not pass the regular URL sanitization, they will
break.

To fix this you need to ensure that the values used for binding to the affected
xlink:href contexts are considered safe URLs, e.g. by whitelisting them in
$compileProvider's aHrefSanitizationWhitelist (for <a> elements) or
imgSrcSanitizationWhitelist (for <image> elements).

  • fd4f01: do not use deepWatch in literal one-way bindings

Previously when a literal value was passed into a directive/component via
one-way binding it would be watched with a deep watcher.

For example, for <my-component input="[a]">, a new instance of the array
would be passed into the directive/component (and trigger $onChanges) not
only if a changed but also if any sub property of a changed such as
a.b or a.b.c.d.e etc.

This also means a new but equal value for a would NOT trigger such a
change.

Now literal values use an input-based watch similar to other directive/component
one-way bindings. In this context inputs are the non-constant parts of the
literal. In the example above the input would be a. Changes are only
triggered when the inputs to the literal change.

  • 1cf728: add base[href] to the list of RESOURCE_URL context attributes

Previously, <base href="{{ $ctrl.baseUrl }}" /> would not require baseUrl to
be trusted as a RESOURCE_URL. Now, baseUrl will be sent to $sce's
RESOURCE_URL checks. By default, it will break unless baseUrl is of the same
origin as the application document.

Refer to the
$sce API docs
for more info on how to trust a value in a RESOURCE_URL context.

Also, concatenation in trusted contexts is not allowed, which means that the
following won't work: <base href="/something/{{ $ctrl.partialPath }}" />.

Either construct complex values in a controller (recommended):

this.baseUrl = '/something/' + this.partialPath;
<base href="{{ $ctrl.baseUrl }}" />

Or use string concatenation in the interpolation expression (not recommended
except for the simplest of cases):

<base href="{{ '/something/' + $ctrl.partialPath }}" />
ngTouch due to:
  • 11d9ad: remove ngClick override, $touchProvider, and $touch

The ngClick directive from the ngTouch module has been removed, and with it the
corresponding $touchProvider and $touch service.

If you have included ngTouch v1.5.0 or higher in your application, and have not
changed the value of $touchProvider.ngClickOverrideEnabled(), or injected and used the $touch
service, then there are no migration steps for your code. Otherwise you must remove references to
the provider and service.

The ngClick override directive had been deprecated and by default disabled since v1.5.0,
because of buggy behavior in edge cases, and a general trend to avoid special touch based
overrides of click events. In modern browsers, it should not be necessary to use a touch override
library:

  • Chrome, Firefox, Edge, and Safari remove the 300ms delay when
    <meta name="viewport" content="width=device-width"> is set.
  • Internet Explorer 10+, Edge, Safari, and Chrome remove the delay on elements that have the
    touch-action css property is set to manipulation.

You can find out more in these articles:
https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away
https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_9_1.html#//apple_ref/doc/uid/TP40014305-CH10-SW8
https://blogs.msdn.microsoft.com/ie/2015/02/24/pointer-events-w3c-recommendation-interoperable-touch-and-removing-the-dreaded-300ms-tap-delay/

Angular due to:

@mend-for-github-com mend-for-github-com bot added the security fix Security fix generated by WhiteSource label Oct 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
security fix Security fix generated by WhiteSource
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants