current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 4 down vote favorite

Considering sharepoint development is mostly moving to client side with JSOM, REST api exposed. Even in recent announcement we have Sharepoint framework based on Client side.

With this I am assuming MS really want us developers to develop solution based on Client technology.

I had one question considering above. For any application developed with JavaScript etc, the application runs under the context of current user.

So i want my client application creates/edits items in list through front-end,so i Must provide contribute access to all the users. However, if this is little confidential, e.g Leave rquests, reimbursment reqeusts, I still have to provide users contribute access.

If few of my end users have Sharepoint knowledge, they can very much write javascript code and run that in browser developer console and can add tens of thousands of records to the list in few mins.

For a moment thought may be we can have app only policy and control this with permissions, but again sharepoint-hosted apps do not support app only policy.

I would like to know, what is the best way to handle such scenarios i.e. to have complete client based solution and handle the security as well? I understand we can write have server side code etc the old traditional way with run with elevated prev., but m really interested in client bases applications.

share|improve this question
up vote 1 down vote

There's no way you can elevate permissions and similar using client side techniques. If you really want that you need to use client side code to call into "something" server side that does that for you.

Of course you can set permissions on lists, so that you only are allowed to read, read/write or manage the list items. All client side techniques respect the list permissions.

Also, one thing that far to many forget about is the Item-level Permissions where you can specify that users only can see or update their own stuff.

share|improve this answer
    
Thanks Wictor, but I am not concerned about view (GET data) but about create/edit (POST data). If its browser client application, where i want my user to add list item through fancy HTML form, i must give them at least "Add Item" custom permission. I dnt think item-level permission can help. With Add item access ayone can add items through any way not jsut my fancy HTML form. Also for item level permission you have to keep monitoring the list if there is new item added, which u dono when user is going to add. – Rohit 18 hours ago
    
With client side code, it is the permissions they have on the list that matters. So if they can write, they can write, and also write any item in that list. There's no way around that, expect using an external API, as I explain OR by using item-level permissions where you only allow the user to edit their own items. – Wictor Wilen MCA MCM MVP 18 hours ago
    
Hmm okay. I really wish MS adds some mechanism here if they are promoting client side development so much. May be some business rules which can act as secret key , so only items with proper key can be added (just wild idea)Thank you anyways Wictor. – Rohit 18 hours ago
1  
It's not as easy as one may think. If you have that "secret" or whatever - any script can use that one and that would be like open a can of worms. We will see malicious code in scripts in no time. – Wictor Wilen MCA MCM MVP 18 hours ago
1  
I understand, for a moment i thought may be i can use Column validation and put validation such as only I know how to PASS , but again I have to pass that validation through fancy HTML form with javascript which any developer can find by browser debugging. I guess ultimately i have to use server side code to have "Secure" application and just client side development is not sufficient :( – Rohit 18 hours ago
up vote 0 down vote

I think your assumption "With this I am assuming MS really want us developers to develop solution based on Client technology" is incorrect. Without being able to read their minds, it would be fair to say that Microsoft engineers in general want us to move our development away from full-trust code running within SharePoint (and mentioning that this continues to be supported on-premises). The reasons are mainly to support Office 365, but also because full-trust code is a support headache and a frequent upgrade blocker.

But it doesn't have to be client-side technology in the sense of running in a browser or an "app" as it could well be server-side which includes a large number of technologies, including ASP.NET MVC, PHP, NodeJS, etc. etc.

One of the problems with client-side technology is that it is impossible to completely protect the code from tampering and inspection, so there will be many use-cases where server technology is required, or just easier to implement.

Apart from the move away from full-trust, it really isn't Microsoft's job to tell you what technology to use. Their job is to provide you with options, so think of the SharePoint Framework as another option for client-side development. Neither SharePoint Framework alone, nor any of the purely client-side approaches is a great fit for the requirements you describe - you are probably going to need to implement this as a partly or wholly server-side solution.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.