0

I have the following scenario: My Add-In allows to write posts. Any user may "Like" that post. That likes are being saved into a list.

Of course the Add-In needs permission to write that entry into a list. But as (IMHO) I cannot use any elevated privileges inside a SharePoint - hosted Add-In, the user needs to have that permission, right?

So: How can I protect my lists that the user don't just go into the list and modifies the value himself and increases the "likes" for example?

(remark: This is no real-world scenario. I know there are better ways to use a social network-feature. Just wanted to break down my much more complex app)

Ole Albers
  • 8,715
  • 10
  • 73
  • 166

3 Answers3

0

I would make each user's 'like' click create a new item in a list that has the Item-level Permissions set to:

Create items and edit items that were created by the user

That way even if they did somehow get into the back end and start monkeying around with the list they would only be able to change the items they created.

You'd just need to manage how the list grows over time depending on the scale of the app.

John-M
  • 653
  • 5
  • 8
0

SharePoint-hosted add-in cannot use App only policy as provider-hosted add-in can to use add-in context with more permissions then user has. SharePoint-hosted add-in is running completely in the context of current user.

I see 3 possible solutions:

  1. Redesigning the add-in to be provider-hosted)
  2. Implement custom web service and calling this web service from your add-in. That web service can store sensitive information in either custom database or list in app web with customized permissions. But remember that SP admin can modify these permissions.
  3. Store semi-sensitive information into extended properties of item. There's no UI allowing user to manipulate with it but this is not as secure as permission. Advantage of this is that this information is directly connected to the "affected" item and you don't need to afraid of loosing connection between item and like storage. Disadvantage is that extended properties can contain only limited amount of data and user must have permission to update item. You can also use this approach combined with your list.
Jan Vanek
  • 889
  • 1
  • 6
  • 8
0

You are correct. The user would require the something like "Contribute" permissions to accomplish what you are talking about. Personally, here is what I would do...

1) Ensure the list I want to protect has an obscure name. Remember, the UI is not the same as in the host web (i.e. Site Contents). The user never has to know in what list such data is stored. Taking it a step further, ties between lists could be made by something like a GUID instead of something obvious like "Title", making it more difficult to determine exactly how data relates.

https://sharepoint.stackexchange.com/questions/96360/hide-list-from-browser-site-lists-lisname

2) Delete all views in your sensitive lists. This would prevent navigation in the browser. These lists would be modified through REST or CSOM, so you do not need them.

3)I haven't tested this possible solution, but it may work. You should be able to configure the edit.aspx (or create your own custom one) so that even if the user somehow made it past Steps 1 and 2, there was no available fields to edit anyways...

These methods do not manipulate the permissions to the list in any way and in the end, all of this is permissions through obscurity.

MadTaz
  • 1
  • 1