7

I am writing a public facing web site in sharepoint 2010 and using JSOM to access data from lists, Things are working and now trying to deploy on production server, server has strict security settings for anonymous users and anonymous users have no access to _vti/_bin folder.

Breaks everything.

Following article says it is not a good idea to use JSOM for public facing web site. https://docs.microsoft.com/en-us/archive/blogs/kaevans/what-every-developer-needs-to-know-about-sharepoint-apps-csom-and-anonymous-publishing-sites#enabling-csom-for-anonymous-users

Is there any way to get around this issue, or I have to rewrite whole application?

I could not find any reason to block _vti_btn folder, an article is availble on MSDN but that targets sharepoint 2007 only, nothing for sharepoint 2010.

I have checked in developer tool bar that client.svc and sites.asmx are used to read items from the list, I will try to convince my client to block whole folder except these 2 services, another important thing I have found is that these services can only be used from my sharepoint application, user cannot read list information by typing url in the browser.

Improve this question
1
  • 2
    Argg, that's why I hate CSOM/JSOM ways... Hearing that it is the future makes me lose my faith in SharePoint (and computers). See my answer below. – Evariste Jul 27 '15 at 13:49
1

Create a custom web service that allows for anonymous access.

The client connects to the custom web service, which handles pulling the data from SharePoint. The web service runs on a non-SP server and uses its own credentials to connect to SharePoint. It then passes the data back to the client, where it can process similarly as it would have with JSOM.

Improve this answer
10
  • this is irrelevant answer because, the question is related to 2010 and you are answering on app model which came only in 2013. pls edit the answer. – kesava Jul 27 '15 at 19:46
  • @kesava good point - the first part of my answer related to SharePoint Apps. I'll remove it. – Hutch Jul 27 '15 at 23:37
  • If I write a custom web service which is available for anonymous users, would it not be a information related security issue? If you have a developer tool bar, you can easily check url of the service and open in a new browser and information is visible to you, this may or may not contain sensitive information, another thing is to write a script to ping this web service every second and it will definitely increase the load on server. – Ali Jul 28 '15 at 0:04
  • @ShafaqatAli: If the web service is only publishing publicly-available data, shouldn't be a security issue - you're only publishing the specific data you want, not all data on the SP server. And yes, repeatedly calling the web service would increase the load on the server - just as calling the built-in SP services (via the JSOM model) also would. – Hutch Jul 28 '15 at 15:43
  • JSOM will be in my control and can only be called from my code but web service are open to public, anybody can write a script to call web service every second. – Ali Jul 28 '15 at 23:24
7
+25

One very common workaround I see is that you use an authenticated user to pull the Request that you need, then write it to a document library that allows anonymous access. Because most SP does not accept .json as a file type, just save it as response.txt

Then, in your public site, anonymously read from that document library:

$.ajax({ url: "/documents/response.txt", dataType: "json", method: "GET", cache: false })

This will return you exactly what the rest call to _vti_bin would do. Which allows your existing logic to run.

If you want to, schedule a workflow or powershell to generate the txt file daily so it's up to date.

Improve this answer
3
  • @Shafaqat Ali may be using a lot more in JSOM code than what a "simple" REST/JSON will return... He uses JavaScript/JSOM code, not only one REST call... – Evariste Jul 29 '15 at 6:35
  • 1
    Despite the tag change in an early edit, re-engineering a webservice to work with anonymous JSOM is significantly more work than using this approach and REST. Additionally, since you're deciding what JSON data you want to put in the library, you would be able to perform read actions for pretty much any data you could need as long as you could retrieve it somewhere from your site. From a practical standpoint, this is the approach I would probably use for anonymous client-side access. – John-M Jul 31 '15 at 11:54
  • This is also an approach that will work when/if you head into Office 365. Writing custom full trust solutions service end points will work well for SharePoint on-premises, and is something I promoted heavily in the past, but it isn't really the future. I would recommend re-engineer any JSOM calls into REST calls and just cache the result REST output in a document library. – John Liu Aug 4 '15 at 1:20
4

In such situations, the only viable (i.e. open to evolutions) approach would be to deploy an applicative page (or Web service) in _layouts via a WSP. That is, a WSP with server-side code. That page/Web service would hold all the logic/intelligence/business (with elevation if needed, or as the anonymous user to preserve security, but at least you'll be allowed to do what ever an anonymous user is allowed to do), and your client code would only call it to get everyhting served on a silver platter.

Any other way would be a very short-term fix, with a lot of side-effects/latencies/etc.

Improve this answer
4
  • Deploying an application page would be an option - it would need to derive from UnsecuredLayoutsPageBase instead of LayoutsPageBase. I would personally recommend against building a web service in the _layouts folder - we have done it but it ended up being very messy. – Hutch Jul 29 '15 at 15:04
  • Err - I should be more precise. A WSDL-type web service was troublesome to put in the _layouts as getting SharePoint to handle all the calls properly was frustrating. A RESTful service would probably be fine to implement inside the _layouts folder. – Hutch Jul 29 '15 at 15:09
  • Yup, a page from UnsecuredLayoutsPageBase was exactly my idea. A Web service is also an option (I've already done it several times) but it does not specially bring killer advantages over a simple page. Also, such a Web service would be a bit broken in regards to all WSDL discovery, proxy creation and other norms (due to the "virtual" aspect of the "_layous" folder). So, as @Hutch stated: a simple UnsecuredLayoutsPageBase is probably good enough! :) – Evariste Jul 29 '15 at 15:12
  • Thinking of it, I'm wondering whether a classical LayoutsPageBase would not work here: as long as your code-behind performs operations allowed for Anonymous users, that should be OK... – Evariste Jul 29 '15 at 15:13
0

I agree with the above answer, you could save your js or css files into library (as Style Library) which could be published to everyone and even anonymous users. You just need to configure this library for anonymous access. You can keep all the architecture of your app, and just to modify the link of referenced files.

Improve this answer
1
  • That would be true if @Shafaqat Ali only used REST calls... but if he uses JavaScript OM, as I suspect, everything on the client-side is to be reworked anyway... – Evariste Jul 27 '15 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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