I have Silverlight application set in Sharepoint webpart. The application modifies Sharepoint lists using client object model.
What I want to achieve is to provide some security for these lists. The idea is that users should be able to modify lists only by my application. Modifying by SharePoint UI shouldn’t be possible for users.
I know that something like that could be achieved using web services but my question is whether is it possible using client object model?
Thanks for any reply and sorry for my English.
Chris
The short answer is no. The user will always have a context and be allowed to edit based on that logged in context and the list permissions.
You could try other tricks such as hiding the lists and adding controls for the edit/new forms that based on a user not being part of an admin group, simply refuse to show the list information in the normal manner but allow the list information through your Silverlight application.
Related
A client's employee base is struggling with using sharepoint UI as an interface. As a result the client is evaluating the option of building a custom UI on top of sharepoint to provide a better user experience; [The other option being to move away completely from sharepoint (non trivial, high cost option)]
My research indicates that you can customize the UI look and feel (but the client is looking for much more).
Another option appears to be to change/improve the experience by building PowerApps
The option I have been trying to assess,is to see if sharepoint provides adequate set of APIs/integration interfaces that allows the user to build a completely independent UI and user experience. Its effort intensive ofcourse, and feels like reinventing the wheel, and am wondering about whether others have faced similar UX callenges, and what possible solutions they might have evaluated, and path they have gone ahead with.
Under the covers, SharePoint is a SQL database and a collection of .NET classes that define each SharePoint object: SPWeb, SPSite, SPWeb, SPList, SPUser list item, document etc. Most of these objects are exposed via web services. Microsoft then built an IIS/ASP.NET based UI for the out of box user experience. There are mobile apps that are not browser based that call the SharePoint REST services to read and update lists and libraries. If you wanted to, you could built your own complete UI based on just about any technology. Is it worth it? Probably not. There are many customization options available, depending on your version of SharePoint.
(If I could post comments... :-) I would then ask: Tell us more about what the users need in the UI that is not supplied by out of the box SharePoint.)
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)
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:
Redesigning the add-in to be provider-hosted)
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.
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.
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.
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.
My company is running its own server with WSS 3.0, and I am using Sharepoint Designer 2007 to make changes. I am new to the world of sharepoint (but experienced with webservers and web programming), but basically what I am trying to accomplish is this:
We are trying to automate forms that all employees must fill out (for example, our Employment Application). Since all employees have access to our sharepoint intranet, we will put it on there. It must do the following:
Display a form where users can enter their data. Once submitted, the data is stored in a database (sharepoint uses Lists for this I believe).
A user can go back to the form to edit things if need be (and their old data will be automatically loaded).
User’s should only be able to access their own form and not see everyone else’s. Only admin’s should be able to see everyone’s stuff.
What is the best way to go about accomplishing this? Can I create a standard list and modify it to suit my needs? Do I need to code some ASP forms to make this work? Is there an inexpensive web part that can do this sorta stuff?
I don’t think using Infopath is an option for me since I have wss 3.0 I would need the end user to have infopath as well, and many won’t have it, so that rules that out.
I think you want to adjust the Item Level Permissions setting of the list. (List Settings->Advanced Settings)
The form in SharePoint States:
"Item-level Permissions
Specify which items users can read and edit.
Note: Users with the Manage Lists permission can read and edit all items. Learn about managing permission settings."
There are settings for Read access and Create and Edit access:
Read access: Specify which items users are allowed to read
-Read all items
-Read items that were created by the user
Create and Edit access: Specify which items users are allowed to create and edit
-Create and edit all items
-Create items and edit items that were created by the user
-None
This sounds like you simply need a custom list, possibly with custom forms (edited with SharePoint Designer) in case the default forms aren't adequate.
Is it possible in a SharePoint 2007 list (MOSS, though I don't think that this is Enterprise Edition) to allow users in one SharePoint group to edit values in some fields and users in another group to edit values in the other fields?
From all the searching I've done, this does not appear to be possible, so as a fallback I'll accept answers that suggest the best way to accomplish something like this (e.g. maintain the items in separate lists, linking them by ID).
I do not have access to Central Admin, but I do have Full Control of the site. Also, this site was not configured for custom code, so besides changing list settings (and site settings) I can make changes via SharePoint Developer (but not Visual Studio).
A big THANKS in advance!
Steve
You are correct that it's not possible to set field-level permissions without custom code. Furthermore, you're on the right track thinking separate lists, though you should be aware that SharePoint list lookups are a rather weak correlation. Usable, but not exceedingly robust.
For presenting the combined data you'll want to look at SharePoint Designer's joined subviews.
Have a look at Displaying SharePoint Fields by Permission Level by Laura Rogers. This is an approach that uses SharePoint Designer.
Also see the SPListDisplaySetting CodePlex project. This is a site collection feature that needs to be installed so may not be an option.
You can customize Edit Forms for SharePoint 2007 Lists (EditForm.aspx).
With custom list definition and custom edit form you can write code to check the user and show different fields depended on the users permissions.
'a' workaround to get this functionality is to change the content type associated with a list item using workflows.
Like so:
User creates list item in content type A (limited fields).
Workflow starts, changes to content type B (all fields).
Admin gets notified, opens listitem, fills out additional form fields.
And so on..
I am creating sharepoint custom solution that will show number of drop down in page. The drop down data is shared in may pages.
I want to persist selected values of the user such that when ever he visit that page or any other page that have same drop down, he should be able to see is saved value pre selected in drop down.
To implement this I have a number of options. Please suggest the best for SharePoint
1)Sharepoint User profiles
2)Sharepoint list
3) Cookie
4) Isolated storage?
Options 3 and 4 here are clientside. But I am looking for any other way that SharePoint provides to save user preferences/personalization information.
Which one is the correct way of doing that in SharePoint?
Thanks
One issue you should be aware of with user profiles is that they are only available for MOSS (as opposed to WSS). In WSS each site has their own User information list. If the solution you are building will need to run in both MOSS and WSS environments, you should plan accordingly.
jt
My instinct tells me to use cookies for this, if it's a fairly simple state you need to persist. This seems to be a part of the UI logic, and I wouldn't bind that to the profile storage.
Pages and web parts have personalization stores as well, but they are generally not shared between instances.
I would go with profile storage, because that's the sort of thing it's there for, although generally when you are writing custom code in SharePoint the idea of best practices kind of gets thrown out the window.