Gotchas
- I ran into an issue in Internet Explorer where when I tried to send ANY of the AJAX messages, the request was redirected for authentication, however, it wasn’t an issue in Firefox or Chrome. If I loaded the Internet Explorer F12 developer tools, I discovered that the AJAX request was returned with a 302 Found response, where the request was then routed over to a SharePoint page, presumably for authentication. An OPTIONS request was then made that ultimately terminated with a 405 Method Not Allowed response. It looked like this:
During further investigation, I compared the cookies that were being sent from Chrome (which worked fine) vs. IE (which didn’t work). What I discovered is that IE wasn’t sending the same cookies. Chrome sent these cookies:
And IE sent these cookies:
It turns out that the issue had to do with IE not trusting pages loaded within an iframe, which is how web parts are loaded into SharePoint. The easiest solution was just to add the Azure website address to the IE Trusted Sites, like so:
However, based on some additional research (which I didn’t test or verify), a better long term solution would be to create and publish a privacy policy, as described here: http://www.w3.org/P3P/details.html, which would then allow IE to automatically trust the iframe page.
2. I had an issue where Ping requests weren’t being received by the HomeController, despite AJAX reporting that the request was sent successfully. As such, users were automatically logged out of the chat room because the cache was expiring. It turns out that the request was being perceived as a duplicate request as before, and as such, the web server was providing a cached version of the response (which is null), without actually executing the action. Adding cache: false to the Ping request (and all of the other AJAX request, just for safe measure) resolved the issue. I probably could have also configured the controller action to not send cached responses, but I didn’t try that since this worked fine.
What else?
Well, certainly the point of this walkthrough was not to describe how to actually build a chat room, but rather to describe some of the possibilities around SharePoint, SignalR, and Azure. Some of the use cases that come to mind regarding the use of this set of technologies include:
- A queue based system, such as a Help Desk or a Pharmacy system, where requests are added and are processed in a particular order. Using SignalR would prevent the need to somehow refresh the page on an interval.
- A notification system, where, perhaps a service becomes unavailable and an operator or engineer needs to take some kind of action.
- Games! Certainly SignalR would allow multiple users to interact with each other in some sort of game. Check out: http://shootr.signalr.net/
- What else?
And, if you did want to expand on the chat room, what could you add? Things that come to mind are:
- User selectable fonts/colors.
- Images
- File transfers
- A list of members that are currently in the room
- Video/screen sharing…would that even be doable?
- More?
Conclusion
SignalR is a sweet new-ish technology that opens some doors that were previously much harder to open. Coupled with technologies like SharePoint and Azure and many, many possibilities start to arise.
Enjoy!
Part 1: Create the SharePoint Online app and associated website
Part 2: Test the app in Visual Studio
Part 3: Create the SharePoint Online web part
Part 4: Deploy the site to Azure