After a while of struggling, I could eventually benefit from an Office 365 environment for which I had already developed a solution. The first thing I did was of course to test my solution with Office 365.

First, a bit of history : I developed a rating solution for SharePoint 2007 & 2010 (Foundation) and I've been asked recently to embed that into a SandBoxed solution.
Therefore, I decided to dig into it and I targetted specifically public facing blogs with Office 365. The purpose of the solution was to allow rating/commenting on blogs and to enhance the administrator experience.

What I knew in advance was that the only way to customize Office 365 with code-behind is using Sandboxed solutions. They come with a lot of advantages but also a lot of restrictions.

Since my investigations target more precisely the Office 365 public facing site, another important element comes into play : the anonymous access.

That ingredient raises the following question : How to tackle Office 365 public site with anonymous access and Sandboxed solutions?

• Problem number 1 : anonymous access is enabled in the Office 365 public site but in reading only. There is no way to enable write access on a given list for anonymous users.
  
  
• Problem number 2 : Sandboxed solutions do not allow impersonation.

Since Sandboxed solutions are the only way to add code-behind customizations to Office 365, you already understand that it is going to be difficult to allow anonymous users to input data in a way or another into a SharePoint list.
Within a farm solution, one could impersonate using the site collection administrator token but this is not possible here...
Given the above, I quickly understood that I could forget about writing data into a SharePoint hidden list with anonymous. While this was not really a very good design, this could have been a potential solution.
I suppose that the reason for not allowing this is probably due to a potential security hole that would allow malicious users/robots to fill your lists unexpectedly without being authenticated.

Ok, I fully understand but then, why don't we have a kind of SPSecurity.RunWithElevatedPrivileges_ identity so that we can leave the ACL on lists and use that impersonated identity to perform writings in a *secure* manner?

So ok, it seems that storing an information into Office 365 public site with anonymous is impossible...So, let's say that my solution is much less interesting but I could still decide to have a read-only mode for everyone and a read-write mode for authenticated users.
Great, let's try that! One could think, since reading access is given to anonymous, it shouldn't be a problem but, I met the following :

• Problem number 1 : I am using ECMAScript to make fancy webparts with AJAX etc...great but the following

  SP.ClientContext.get_current().get_lists().getByTitle('alist').getItems(aquery)

  won't work because the getItems() method is disabled (why?) by default by the configuration of ClientCallableSettings. On a regular SharePoint environment, one could ask the administrator to enable it via PowerShell. This is a SPWebApplication property.
  
  

• Problem number 2 : since Sandboxed solutions cannot make use of SPWebApplication objects, we can't change the setting...
  
  
• Problem number 3 : in the administration console of Office 365, there is no way to specify another behavior for the COM APIs

So, I thought writing was the only problem but actually reading is also a problem...So, what are the alternatives to create AJAX enabled components that read SharePoint data?

• Alerternative number 1: Using ListData.svc together with jQuery/oData? Well thought but just try, I couldn't get it working :). Adding _vti_bin/ListData.svc behind any URL hangs for ages...is it due to a temporary/local problem or not, don’t know!
  
  
• Alerternative number 2 : Using server-side AJAX ASP.Net controls/extenders? May be, i've not tried but we might expect to hit any of the Sandboxed limitations.
  
  

Ah, I had forgotten one solution that for sure works (didn't try but I bet a lot on it):

• Alerternative number 3 : using our good old Lists.asmx combined with jQuery.

Yeah that one for sure should work but isn't it a pity to revert to old development techniques while the COM APIs are a much more easy and controlled way to access SharePoint data and handle the AJAX plumbing?

So, in conclusion, I can say that at the time of writing & according to my findings, I'm a bit frustrated by all those limitations I met and I wonder whether I miss something obvious (I’d be glad if you tell me “You’re an idiot, you should have done that…” or whether this is really the only options to handle public facing sites with Office 365...

That said, Office 365 is very promising & exciting as SharePoint 2010 is and that's why this makes me even more frustrated :).