I am little bit confused by msdn article, As per msdn article “AllowUnsafeUpdates is set to true when you are trying to update the database as a result of the GET request”.
I understand that we have to set web.AllowUnsafeUpdates=true while updating database and set it back to false after updating the database, But what means "as a result of the GET request"?
please, someone explain it to me.
The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. But the specifications also give the usage recommendation that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail. [R1]
When you visit a page with code-behind in it, it is all happening in the context of a HTTP GET request. SharePoint prevents all updates made to the database from a GET request to protect from cross-site scripting attacks. That's when you need to use AllowUnsafeUpdates if you want to update an object when the only thing you were supposed to do is read data. You don't need to use AllowUnsafeUpdates every time you update a database - for example as a result of a POST request.
Example:
A SharePoint example of a GET request would be: Let's say you have a SharePoint application page where you add site administrators by using a GET request - i.e. there is a button on the page which, when clicked, collects the information from the form (let's say user name and other details) and then redirects the user to the following URL with all the parameters encoded in the query string - Response.Redirect("http://yourserver/_layouts/admin.aspx?operation=addAdministrator&username=name"). That admin.aspx page handles OnPageLoad event and adds the user to site collection administrators. What happened here is basically a user sent a GET Request (with all the information encoded in the query string) to do a database update (add an administrator to a site). This is where you would get the following error:
System.Exception: Microsoft.SharePoint.SPException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again. —> System.Runtime.InteropServices.COMException (0x8102006D): The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.
This is when you would need to set AllowUnsafeUpdates to true in the OnPageLoad event:
bool unsafeUpdates = web.AllowUnsafeUpdates;
web.AllowUnsafeUpdates = true;
//add site collection administrator
web.AllowUnsafeUpdates = unsafeUpdates;
While normally a POST does not offer much protection against this, SharePoint has a concept of form digests, which contain information about the previous request that is generating the post back (including the user's name). This reduces the footprint for this kind of attack significantly. [R2]
So doing a POST request would be sending all the information encoded on the FORM instead of URL. So there would be no need to set AllowUnsafeUpdates to true.
If you are running your code from a rich client application - like PowerShell and the HTTPContext.Current is null then AllowSafeUpdates will always be true. This is the case in rich clients where no cross-scripting is possible as there are simply no web requests. This as well is a case where you don't need to set AllowUnsafeUpdates to true.
There is a very fine article which explains AllowUnsafeUpdates in depth - HERE.
Hope this helps.
Quoted resources:
[R1] - https://www.cs.tut.fi/~jkorpela/forms/methods.html
[R2] - https://stackoverflow.com/questions/213882/best-pattern-for-allowunsafeupdates
First let’s look at what’s happening in the context of making these changes via the web UI. In SharePoint there is a FormDigest control, this control places some security validation information into the page which is included in the POST back to the server. SharePoint uses this information to verify that this request to change the contents of its databases does correspond to a request from a page that was served up by SharePoint.
Now when we attempt to make these changes from custom code that’s getting executed from PowerShell there’s no page, no POST and no FormDigest information bundled along. So SharePoint attempts to verify the form digest a.k.a “security validation” and in the interests of self protection quite rightly throws an exception. This behavior of SharePoint wanting it’s changes to come from a web browser can also present via the message “Updates are currently disallowed for GET requests”.
Of course because what we’re trying to do here is a valid use case SharePoint supports disabling these checks via the AllowUnsafeUpdates property on the SPWeb object.
Hopefully this has helped to explain the WHY behind the use of AllowUnsafeUpdates !!!
SPWeb.Features.Add), so I want to know ifwebobj.AllowUnsafeUpdatesneeds to be set to true under those circumstances. – Web User Dec 09 '17 at 21:29