user can't update its own data (401)

[Morriz]

The loopback angular model.$save (or Model.update for that matter) defaults to $upsert, which tries a batch update on the server, which is not allowed for just the $owner. The PUT method for a logged in user in the explorer works though.

Difference in calls is (while using same body payload):

explorer PUT: /api/Users/someid (allowed)
loopback-services.js PUT: /api/Users?id=someid (not allowed because of reason mentioned)

output after call from loopback-services.js:

loopback:security:role isInRole(): $everyone +0ms
  loopback:security:access-context ---AccessContext--- +1ms
  loopback:security:access-context principals: +0ms
  loopback:security:access-context principal: {"type":"USER","id":1} +0ms
  loopback:security:access-context modelName User +0ms
  loopback:security:access-context modelId 1 +0ms
  loopback:security:access-context property upsert +0ms
  loopback:security:access-context method upsert +0ms
  loopback:security:access-context accessType WRITE +0ms
  loopback:security:access-context accessToken: +0ms
  loopback:security:access-context   id "KCXtsjtfaDpwMh2IExPFHCS3DgIAF1oL56hW7mWCbCvVoFcExbzJAWW6DAkVSQAZ" +0ms
  loopback:security:access-context   ttl 1209600 +0ms
  loopback:security:access-context getUserId() 1 +1ms
  loopback:security:access-context isAuthenticated() true +0ms
  loopback:security:role Custom resolver found for role $everyone +0ms
  loopback:security:acl The following ACLs were searched:  +0ms
  loopback:security:acl ---ACL--- +0ms
  loopback:security:acl model User +0ms
  loopback:security:acl property * +0ms
  loopback:security:acl principalType ROLE +0ms
  loopback:security:acl principalId $everyone +0ms
  loopback:security:acl accessType * +0ms
  loopback:security:acl permission DENY +0ms
  loopback:security:acl with score: +0ms 7495
  loopback:security:acl ---Resolved--- +0ms
  loopback:security:access-context ---AccessRequest--- +0ms
  loopback:security:access-context  model User +1ms
  loopback:security:access-context  property upsert +0ms
  loopback:security:access-context  accessType WRITE +0ms
  loopback:security:access-context  permission DENY +0ms
  loopback:security:access-context  isWildcard() false +0ms
  loopback:security:access-context  isAllowed() false +0ms

[joncarlson]

Also experiencing this (not using Postgres). If I change the URL in $upsert from urlBase + '/people' to urlBase + '/people/:id' updates work correctly.

[bajtos]

IIRC, there is an important difference between "PUT /api/people" and "PUT /api/people/:id": the former replaces all properties with the data in the request and deletes any properties not included in the request, while the latter updates only the properties specified by the request and leaves the rest untouched.

@raymondfeng @ritch you are more familiar with ACLs than I am. Is it expected that updateOrCreate is not allowed for $owner role?

[bajtos]

Apparently PUT /api/people (updateOrCreate) and PUT /api/people/:id (prototype.updateAttributes) is all that loopback provides, in which case we have to use "updateAttributes" to update the current user.

There are two things that can be done.

A) Change your Angular app to call updateAttributes instead of save:

// before: User.$save();
User.prototype$updateAttributes({ id: user.id }, user);

B) Rework the implementation of $save (source) to detect whether the id property is set. If it is, then call Model.prototype$updateAttributes, otherwise call Model.create.

[nolandubeau]

I would vote for B.

On Wednesday, March 4, 2015, Miroslav Bajtoš notifications@github.com
wrote:

Apparently PUT /api/people (updateOrCreate) and PUT /api/people/:id
(prototype.updateAttributes) is all that loopback provides, in which case
we have to use "updateAttributes" to update the current user.

There are two things that can be done.

A) Change your Angular app to call updateAttributes instead of save:

// before: User.$save();
User.prototype$updateAttributes({ id: user.id }, user);

B) Rework the implementation of $save (source

loopback-sdk-angular/lib/services.template.ejs

Lines 392 to 400 in fa7668b

	// Angular always calls POST on $save()
	// This hack is based on
	// http://kirkbushell.me/angular-js-using-ng-resource-in-a-more-restful-manner/
	resource.prototype.$save = function(success, error) {
	// Fortunately, LoopBack provides a convenient `upsert` method
	// that exactly fits our needs.
	var result = resource.upsert.call(this, {}, this, success, error);
	return result.$promise || result;
	};

)
to detect whether the id property is set. If it is, then call
Model.prototype$updateAttributes, otherwise call Model.create.

—
Reply to this email directly or view it on GitHub
#125 (comment)
.

Nolan Dubeau
VP, Engineering
Guardly

Sent from my Apple Newton

[bajtos]

As I mentioned in loopbackio/loopback-datasource-juggler#481, another option is to add a new method "prototype.update" that would always update all attributes and which can be used in $save.

[pbrain19]

this issue does not seem to be resolved. Currently trying to update customer and it does not seem to have the ownership to do so.

[rhoderunner9]

The documentation online does not seem to be sufficient to cover how to do simple tasks. I have set up the updateAttributes, and even just threw my hands up and gave $owner unlimited access, and still get the Authentication Required error. This tells me that this user is not the owner of his/her data. The documentation is vast, yet seems to leave many of us hanging with inadequate answers to very common issues. I have gone so far as to set the "property": "update" to ALLOW for $everyone, yet I still get Authentication Required. I'm assuming I'm one of thousands of people spending amazing amounts of human hours on these kind of issues, so could someone clarify how to setup the model update ACL effectively?

[superkhau]

@crandmck Maybe you can help out with the docs here? @rhoderunner9 Do you have any suggestions on how to improve it?