Coding tip #2: fail fast, don’t fail, don’t worry

Facebook recently pulled the plug on one of their data centers…
On purpose.

The idea was to investigate how well they could recover from live failures.

We developers, and beginning developers especially, sometimes have this weird notion that code should be perfect and withstand any storm. Truth is, something can and will always go wrong at some point in time, and we should stop fearing it.

The first, most noticeable form of something going wrong, is an exception that’s being thrown. Beginning developers will often shy exceptions. They’re cryptic and are more likely to happen in the middle of a demo than while developing…

Fail fast

Hence, out of fear of introducing new exceptions by actually throwing one, beginning developers start writing code as:

public object getValue(string key){
  if(key == "CurrentUser")
    return SomeContext.User.Name;
  if(key == "CurrentTeam")
    return SomeContext.Team.Name;
  return "Not found";
}

Peaceful, right? No matter what value you ask for, no exception shall ever leave this method.

The unfortunate thing here if the calling logic is flawed somewhere, you might only find out much, much later in the process.
The above piece of code is called by some EmailTaskPreparer, which retrieves “current_user” to create an instance of a task. That task is put on a queue, one hour later a worker process picks it up and processes it by getting the current user’s email address, then sending an email.
One day later, you get a bug report there are undeliverable emails hanging around the system and you get to embark on the pleasant adventure of backtracking every possible piece of code that is sending emails, putting email-tasks on queues, and how they build those tasks.

The key lesson is: fail fast. If something is wrong, throw an exception on the spot instead of returning a peaceful default value.
The calling logic will still be just as flawed, but at least now you end up with a bug report stating that an InvalidKeyArgument was thrown when the EmailTaskPreparer called ‘getValue’, which will be easy to find, fix and will give you more time to actually get some real work done.

Don’t fail

Obviously, learning to code is all about understanding to take everything in moderation. The next rule of fist is to understand that exceptions are for ‘exceptional situations’ only.
When you have an abundance of exceptions being thrown all over your code, you’ll soon end up with a lot of try-catch blocks, and eventually you’ll end up with a code base that has two new problems:
– the code becomes less readable (at the bottom of your try block are a bunch of alternative code paths that make your logic harder to follow)
– the code becomes slower (the compiler can do less optimizations because it needs to make sure it can handle your expected exceptional code pathing)

To address the first, consider adding logic to your classes that can pre-approve an operation. This is why an iterator has a ‘hasNext()’ function, a command has a ‘canExecute()’ function: you can ask if you should expect something to go wrong, and decide on how to handle that on the spot, instead of 100’s of lines lower in a catch=block. It’ll make your code much more readable. Don’t fail if you could have avoided it.

Don’t worry

Finally, there are very little use cases to actually catch an exception. If you take the two previous rules in mind, exceptions will only occur when something really unexpected happens. In literature, exceptions are considered ‘final’ (the code below where you throw an exception will not execute) because they signify the system has entered a state from which recovery is not expected to be possible and execution should not continue.
Hence, if an exception occurs that you could not possibly have avoided and there’s no way you can recover from it, why bother catching it?
Don’t worry. Really, you should only really catch exceptions in a very limited couple of cases:
– you could not avoid it (no ‘hasNext’, ‘canExecute’, etc) but you still know how to recover from it For example: reschedule the task for later execution
– you want to hide exception details: a general catch-all block that catches any exception, logs it, and throws a new exception that hides any internals specific to the current layer of your application. For example you can should the SQL exception (“Connection failed for user “Bob” with password “Bob123″), only to throw a new generic DatabaseOperationFailedException.*
Beyond the above use cases and a couple of others, catching and handling exceptions should not be a part of the majority of your code base.

Don’t worry, all systems will fail at one point or the other, just try to make sure that when it fails, you’ll have a precise stacktrace and clean codebase to help you trace their cause (or, that you know how to plug a data center back in).

Understanding aurelia.io development prerequisites from a .NET perspective (NPM, JSPM, GULP, KARMA, WTH)

There is this awesome javascript framework called aurelia.io that I’ve been working on and using for a little while now. At a certain point, I feel you’ll owe it to yourself (*if not then at least you owe it to me *) to download one of the sample apps and play around a bit.

Some time ago, when I was trying to do just that, I felt overwhelmed at first. I had limited experience with javascript, HTML and CSS. Aurelia itself looked (is) really easy to grasp, especially since it has a very C# + XAMLesque feel to it. The learning curve still felt steep though, but only because of the surrounding open source stack: NPM, JSPM, GULP, KARMA and the likes. I was like WTH are all of these, and I wish I took 3 minutes to read an absolute beginners blog post like this one to bring my vocabulary up to speed.

Your system

There are some things you’ll need to setup on your system before making the switch to this (or any) open source project…

Git

Git is a free and distributed version control system. In .NET speak: yes it is exactly the same as TFS but it’s totally different. Whenever you want to pull or clone a project (‘check out’) from a server (like github, you’ll need git so your OS understands what the hell pull or clone even means.
Additionally, you’ll often need to execute a command (more about that later). The normal cmd.exe or hipster mac OS alternative will at one point or the other drop the ball in understanding those commands, whereas installing git gives you a ‘git bash’ which looks and acts completely the same as your command prompt but understands how everything in this OSS stack fits together, better.

NodeJS

NodeJS is a platform based on Chrome’s javascript runtime. You could compare this to installing the .NET runtime on your system. To run your aurelia apps, users do not need to install NodeJS first, because your app will run in the browser and use that stack. However, when you are developing apps, you do need a runtime for your tooling to execute in. And that runtime, will be NodeJS.

IDE

You’ll also need an IDE. Your IDE should be an integrated bundle that can do three things: manage your project, execute commands and help you write code.

Unfortunately, Visual Studio ultimate super duper bundle, fails the third requirement as it does not (yet) support ES6 syntax. I know! What a shocker right!

My first alternative was going back to a simple text editor. According to stackoverflow’s 2015 survey, SublimeText is the second favorite one. Once set up with an ES6 plugin for next generation javascript syntax highlighting and intellisense and an integrated terminal/command prompt I realized going back to a text editor was the exact opposite of taking a step back. It’s really, really, really fast. Like: really fast!

A little later, we received a free OSS license for JetBrain’s WebStorm IDE. One of the biggest, noteworthy advantages for me was the integrated (visual) support for git&github. After using it for about 2 months now, it has my love, my official seal of approval, and I doubt I’ll go back to VS for javascript development…

Package managers

Managers… Plural.

NPM

NPM is a javascript package manager. In aurelia, we use NPM because of it’s ability not only to install packages in your project, but also in your tooling. Think of it as Visual Studio’s “plugins”, only you install the plugins in your build process/tooling instead of your IDE.

JSPM

JSPM is also a javascript package manager. In aurelia, we use JSPM because of it’s ability to manage dependencies not only in your project but also in your app while it’s running. Suppose your project uses package A and B. Both A and B have a dependency on package C, but they depend on a different major version: A uses C1 and B uses C2. Whoa, now what? Actually, JSPM will download both version 1 and 2 of C, then when you run your project it will load both C1 and C2 in a different ‘scope’. If some component in A needs something of C, it’ll get the C1 version, whereas a component in B will get the C2 version. WHOA! Think of it as a (really) advanced Nuget.

NPM Libraries

Remember: NPM is used to install tooling, so these libraries are your development tools.

Gulp

Using NPM, you can install Gulp. Gulp runs automated development tasks. gulp watch for example, is the equivalent of your Visual Studio’s F5. It will run several automation tasks like cleaning the code, building it, starting a NodeJS server (like VS starts an IISExpress) and serve up your website (the actual watch part). While you are developing, you can keep the gulp watch command running and any change you do in your code will trigger the complete clean, build & run task chain (in about 0.3 secs) so that your website is automatically refreshed and you can see your changes.

Wait: build? Is javascript built? Javascript itself is not built but it’s a scripting language that’s executed by the browser’s javascript runtime. However, you’ll often use a superset of Javascript (like TypeScript, Dart, … The aurelia team just code in ES6/ES7 (the next and next-next javascript spec)). Because your browser does not understand those, your TS/Dart/ES6 is compiled down (called ‘transpiled’) to plain vanilla javascript that works in any browser.

We use gulp for a number of tasks including building documentation, releasing, etc as well.

Karma

Karma is your test runner. It performs a number of tasks to build the code (like gulp), scan a directory for all test cases and run them lightning fast. Just like gulp watch, you can trigger your test runner with karma start and keep the command running. Any code change will trigger a rerun of affected tests (again: wow) so you can instantly check what you’re breaking/fixing. (More breaking than fixing in my case, but whatev)

Time to play

Armed with this knowledge, I hope you find it easier to go play with an aurelia sample. Set up git and NodeJS from the System chapter, then launch a git bash. Navigate to a working folder:

cd .. #go up one directory, or
cd someFolderName # go into a directory

Now, execute

git clone https://github.com/aurelia/app-contacts.git

This will clone (download) the contents of the a sample app into a folder called app-contacts. When done, navigate to that folder

cd app-contacts

Armed with the knowledge in this article, you should now be able to follow this little guide, and have the app running locally without screaming WTH once. ;-)

John Holmes and the case of the mysteriously missing LightSwitch record

Chapter one: the night of disappearance

The cold wind was howling in the streets when Holmes knocked on Elvis’ door.  “It just doesn’t make sense”, was the first thing Elvis said, “it’s simply… gone”…

Aight, pause please. I’m enjoying high 80s (Fahrenheit) at the moment here in the Caribbean, there was no door (just skype) and Elvis is not the actual name of the developer I was helping. I’ll try fiction again in a couple of years, let’s just get through the story of this missing LightSwitch record I encountered last week because I’m pretty sure one day, someone is going to stumble upon a similar issue and this blog post will save him/her half an hour of being dumbfounded…

Chapter one: (for real this time): a record went missing

So here’s what really happened: Elvis called me up because the LightSwitch desktop application that he was working on was throwing an unexplainable nullpointer exception. Unexplainable, because his flow was really basic, textbook easy even:

a) create a record from a “create new entity” screen (the entity was called a “case”)

b) when the screen has successfully saved the new record, use code to close the “create new entity” screen and open the default detail screen for that case enity

c) a nullpointer exception happens in the _initializeDataWorkspace method on this.Case

I’d never seen this before. Right after successfully saving, we show a detail screen on the same entity and the entity just disappears. I’m pretty sure at that point I spent at least 10 minutes of mumbling “I’m dumbfounded“. We started debugging and piece by piece we were able to reassemble the complete puzzle…

See, each screen in a LightSwitch desktop application has its own DataWorkspace.  This is LightSwitch’ implementation of the unit-of-work pattern, whatever changes happen in one screen get committed as a whole upon saving, and either all changes are persisted to the data source or, in the case of an exception, none.

Since each screen has it’s own DataWorkspace, a single entity can exist multiple times (multiple instances) in different DataWorkspaces.  This also means that, unlike the LS HTML client, when you type code like

this.Application.ShowDefaultScreen(this.Case);

the framework will actually take this.Case, an entity which belongs to the DataWorkspace of the “Create new entity” screen,  and pass only the ID field(s) to the new “Detail” screen.  The new screen will then actually use the ID(s) to retrieve the entity again, this time in its own DataWorkspace.

Chapter 2: the resource segment cannot be found

Sure enough, Fiddler soon revealed that when the second screen tried to retrieve the entity again, something went wrong.

Really wrong.

The exception returned was something along the lines of “the resource segment cannot be found for ‘http://localhost:xxxx/ApplicationData.svc/Case'”

Another ten minutes of mumbling about how dumbfounded I was, went by, before we got an Epiphany…

LightSwitch uses the OData protocol to interact with the server tier. OData uses http verbs (GET, POST, etc) for the ‘action’ (***), and a URI to state which entity you want to do your action on. URI is the keyword here: unique resource identifier. Or translated into normal language: your call to “blah blah blah.ApplicationData.svc/case/123″ means you want me to retrieve the ‘Case’ entities and return the slice identified by “123”.

Get all resources for “Case” and only return slice (fragment) 123.

So basically this was the “OData way” of saying: case 123 can’t be found.

Thanks for being straightforward and all…

But… we just created it. And according to our select * from Case, the record is in the database, then why could LightSwitch not find it?

Chapter 3: if it looks like a duck

The mystery continued with 10 more minutes of mumbling about dumbfoundedness… But then we remembered that there’s actually a filter active.

LightSwitch supports row-level filtering, ideal for slicing your records in multi-tenant or advanced security/permission situations.

And sure enough, this was the case

if(!Application.Current.User.HasPermission(Permissions.FamilyLaw)
  query = query.Where( case => case.AssignedCategory.Name != "Family");

The user we were testing with did not have the FamilyLaw permission any more, effectively causing all cases to be filtered to only show the ones where the assigned category is not “Family”.

Right?

Right?

Turns out, our problem was even a little more subtle…

This LINQ query filters out all the cases that have an AssignedCategory that is not “Family”.

Read that again… The linq query is actually, unintentionally I assure you, adding two filter criteria behind the scenes:

  case.AssignedCategory != "Family"
  seems to be interpreted as...
  case.AssignedCategory != null && case.AssignedCategory.Name != "Family"

Really, LINQ? Really?

Once we rewrote the LINQ query (to allow cases with AssignedCategory == null), our freshly created case entity (which has not yet been assigned to any category) now found its way down to the details screen.

 

*** PS: LightSwitch doesn’t really use HTTP verbs like (PUT, PATCH, …) directly on the OData service.  Because each screen has it’s own “unit of work”, all changes get posted just once, together, to an URI called $batch.  This HTTP “batch” call actually contains all different changes that happened in a screen (delete this, modify that, etc) in a single HTTP call.  Using transactional techniques, all changes then all get persisted in the data source together or, in the case something goes wrong, none of them get persisted.

Meet the new love of my life, her name is Aurelia.io

YEZZZZ! I can finally start spreading the love of the goodness that is named Aurelia, with which I’ve secretly been in love with for a while now. I meant to write about her last week, but an NDA contract prevented me from bragging about her beauty before Rob did.

Wait, who’s rob? Who’s Aurelia? What does this have to do with anything? How does it affect me? And you?

Rob…

Rob Eisenberg’s one of the most genius architects of our era. I’ve been a fan of his work since the Caliburn days, a framework he wrote which made MVVM for WPF/SL/WP/… as easy as possible by reducing boilerplate code and using conventions instead.  Over the last couple of years, Rob created an HTML/JS framework named DurandalJS, a masterpiece which never got the credit it deserved.  Well, except from the fine folks at Google, who hired Rob to help build out the next generation of their popular AngularJS framework.

Late 2014 however, Rob left Google because his colleagues were not as visionary as he was (my words, he was more diplomatic in his goodbye message) and started assembling a team of world-renowned experts (and me) to focus on the first of the next-generation javascript frameworks…

Aurelia…

So ok, enough about my man-crush on Rob and his hyperthreaded brain, let’s focus on this beauty of this open-source framework that’s called aurelia. Why would this framework be any better than it’s “competitors”, like EmberJS or the next AngularJS?

I could copy its major strengths from the aurelia.io homepage,  but I’d rather highlight three really important ones (which is not to say you shouldn’t head over to aurelia.io right now to look at her in her full glory):

  1. ES6. If clarification is needed: ES6 is short for EcmaScript 6, the next generation of javascript. It’s just a (finished) specification at this point, since none of the major browsers actually fully support ES6 yet, so aurelia is written in ES6 but then ‘compiled’ into current javascript (ES5).  In the gitter channel, an open chat channel where you are all welcome to discuss anything aurelia, I’ve seen Rob look at the next-next HTML (thus: HTML7) specs, to analyse how we should build the best (most future-compatible) API’s. Long story short: Aurelia is ready for the future, today.
  2. MV* architecture with conventions. Lots and lots of conventions. Aurelia assumes a ton of things out-of-the box, and you can add your own conventions. Got a VM named customer.js and a V called customer.html? Aurelia saw what you were trying to do there. It wasn’t that hard to get either, so why should developers have to write code/configuration to bind those two together? Write code only once and especially: avoid writing unnecessary code (and yes if you don’t like a convention you can always override it). Which seamlessly brings us to the next highlight:
  3. Extensible HTML… As a technology enthusiast, I get a nerdgasm just looking at aurelia. However if one must build large LOB applications, writing HTML all day is too granular to make any kind of progress. However, thanks to aurelia’s extensible HTML compiler, things like <barChart xAxis.bind=”months” yAxis.bind=”sales” /> all the sudden, become valid HTML.

Pause.

Think about that for a moment…

This means that me and you and anyone can write reusable building blocks which are an abstraction level higher than HTML, without actually hiding/losing control over the underlying technology stack!

Me? You?

You and me shared a love for RAD,that’s for sure. And Aurelia is not RAD at all and certainly not a better version of anything like LightSwitch.

Yet.

Aurelia is only the tip of the arrow currently loaded on my bow.

Late last year, three of my LightSwitch customers (and two more are in discussing phase) and I actively started looking at a newer tech stack to phase out LightSwitch if the day would ever come LS is announced ‘dead’.

We looked at so many RAD frameworks and were impressed by a quite a few, but convinced by none. Most RAD frameworks work great for small and simple CRUD apps, but suffer from either poor testability, modularity, scalability, extensibility, most likely all of the above.

Hence, we’re currently building out a super-framework ourselves based on Entity Framework, Web API (CQRS architecture) and aurelia. I use the term super, not only because it is super and kicks ass, but mostly because the intent of our venture is to take all boilerplate and repetitiveness out, and build out applications using a ‘higher abstraction of code’. A super-set of traditional code. Much like LightSwitch used graphical designers as a higher abstraction of all the code goodness it generated “under the hood”, however this time we’ll still have full control of what’s on top of the hood, “under the hood”, and the hood itself.

This’ll keep me very busy during the first part of 2015 (during which I still have LightSwitch projects and will share whenever I can share any LS goodies), then afterwards will undoubtedly be a large part of my future for quite some years to come. Perhaps your future too, as it’ll all be open for your LOB app development pleasures. If you’re in a position where you need a modern, open and future-proof stack for business app development now, please do get in contact so we can work together asap, or at least let me know about your special requirements so I can make sure we can develop this thing as smart as possible.

The future starts today. I haven’t been so excited about tech since a few years ago and am really happy to be a part of, from the start of, this beauty.  Aurelia really is the first of a next generation of frameworks, you owe it to your future self to take her out for a spin. If not today, then tomorrow.

If she looks too high-tech or too granular for you or to make LOB apps today, give it a little bit of time too. We’re at the start of this journey and I’ll put in the effort to make sure she’s worth the venture!

 

So what’s the deal with that announcement?!?

I wish I could tell you. No seriously, I deeply apologize for the extreme hopes my last post left, but I’d be breaking my NDA if I’d talk of this before the official announcement, which was planned for today but apparently needs a little more preparation before it’ll take public form.

Perhaps, no surely, I shouldn’t have put a specific time-frame in my last post.

I hope tomorrow, or later this week, I can undo this disappointment of this post and wash off the smell of rotten tomatoes, that you may now rightfully throw at me, by sharing the goodness that is this novelty with you!!

It’s 2015, and LightSwitch is dead… Now what?

In case I haven’t seen you yet this year (and chances of that are high since I spent almost all of my time in my hammock so far), happy new year to you!

Just two weeks ago, the year turned 2015, always a great opportunity to reflect upon the past, and to learn lessons for the future.

And what a harsh lesson 2014 has taught us: LightSwitch is dead.

There, it’s out, and apparently I’m the first one to publicly carve these words in cyberspace. But unfortunately, a rose by any other name is still a rose, so let’s just call it what it is: dead.

Stage 1: denial

Let me first shed some light on why I consider the lightswitch to be in eternal off-state: there have been no new substantial developments since the HTML client (you weren’t really sitting around waiting for the O365 stuff now, were you), the ‘team blog‘ hasn’t had any meaningful posts in over half a year and many of the active community bloggers have either changed blogs, or have only been writing about using LightSwitch in combination with other technologies (with most of the focus on the other technologies).

If you want to try denying a technology being dead simply due to lack of evolution, then here’s a quote from the team latest post:

we’re currently planning to actively engage with the community and start our discussions on the roadmap in the middle of next year

Our love is dead, and you have been feeling it for a while now.

Perhaps you haven’t admitted it to yourself. Perhaps you are still in denial, but in this fast-paced world of ever-evolving technologies and agile methodologies, I cannot consider the product of a team that shifts priorities for over a year as the solid foundation for my own work.

Stage 2: anger

If you want to, please do take a quick break from reading now to go to the gym, box club, or whatever else you usually do to vent your anger. If you happen to have any pitchforks and/or torches, you could even join the rest of us in our march in the MSDN forums too, there’s a lot of anger already shared over there.

Stage 3: bargaining

We’re still reflecting the pain of 2014. Those of us who were able to overcome denial and anger stages, started bargaining. End of September, I’ve personally sat down with Microsoft folks to talk about the idea of how providing limited extension points so the community would allow us to create a toolkit to address a lot of the missing features. Others have publicly pled to open-source the entire stack, which would fit in great with MSFT’s latest vision and announcements about open-sourcing parts of their stack.  Some have threatened to mail Mary Jo Foley, others to mail Somasegar, in a passive-aggressive attempt to bargain or even blackmail the team into action.

Unfortunately, none of that led to change.

Stage 5: Acceptance

You skipped stage 4: depression.

You just scrolled up and noticed I did not write about stage 4: depression.

Stage 4 in the Kubler-Ross model (‘the five stages of grief’) describes the emotions of sadness, fear and uncertainty that start to develop during the earlier stages.  Feeling these emotions is natural, personal, and shows that we are slowly entering the final stage: acceptance.   So let’s cut to the point and discuss what acceptance could bring, for me and my relationship with you, my highly valued readers, and you’ll see there is very little sadness to be found.

  • LightSwitch being dead does not mean it does not have a future. At some point, probably end 2015 or early 2016, we’ll see a next version from the same MSFT team. Personally I don’t think they’ll actually revive LightSwitch as some kind of frankenstein monster with new body parts, but instead reuse only their experience can into a new product with a new name and marketing strategy.
  • LightSwitch being dead does not mean it ceases to be important in 2015. Personally I have a ton of ongoing projects and consulting opportunities, and they all still stand valid. LightSwitch has always been a tool to create CRUD-oriented, small to medium sized applications, and that is still true regardless of the evolution of the platform itself.  If LightSwitch is the right answer to a particular problem, then File>New>LightSwitch Application here I come! Or as the team puts it:

If the support we have in Visual Studio 2015 meets the needs of your application, then you should feel confident in developing with LightSwitch or Cloud Business Apps as we build out the roadmap

  • This implies an ongoing commitment to my own blog as well. I’ve always blogged strictly about my own professional experiences, and if I encounter anything worth sharing and I find the time to do so, I will gladly blog it! Being it about LightSwitch, or something else…

So there’s the big cliffhanger… What something else?

What now?

There’s not much presently existing that can match the development speed of LightSwitch. However, because LightSwitch does not offer modularity, has bad testability and devastating performance for medium to large applications, I’ve been looking for alternatives to answer challenges that LightSwitch can not…

And I have found it too.

I have found my sweetspot combination of a technology stack that is completely open source (no longer dependent on MSFT management decisions), highly scalable, highly modular, highly performant, fully customizable but yet offers incredible speed of development.

“No way”, I hear you say, “Such a thing does not exist! If it existed, I would have surely heard about it”.

And you are right in saying so. Such a thing does not publicly exists… Yet. But so far, I’ve been mainly writing about 2014, and 2015 is still so very young. This coming Monday, in an announcement that is not my own, the first tip of this veil of secrecy that holds my future, and perhaps yours, will be lifted…

Leave my endpoints alone!

By default, LightSwitch apps expose the server tier by one public OData endpoint per data-source. Both the desktop and the HTML client make direct calls to these .svc urls to retrieve the data they need.

So here’s an interesting question I got this afternoon: this means that all data is publicly visible?

Well, yes and no. The endpoints are publicly visible, however when you access them, the LightSwitch (actually asp.Net) framework’s authentication and authorization will kick in to protect the data (authentication determines if you can access the endpoint, authorization determines if you can access that particular entity set and what records you can access).

However, there’s some cases where you want to protect your endpoints even more, for example when you’re forced to build an application without authentication, or if you want to prevent a user with a valid username&pw (or windows credentials) to access the data from outside your own apps.

In that case, you can add a custom IHttpModule. This would include registering the module in your web.config…

  <system.webServer>  
    <modules>
      <add name="CustomHeaderModule" type="StrongNamespace.HttpModules.CustomHeaderModule"/>
    </modules>

and adding whatever code you want to your server project…

using System;
using System.Web;

namespace StrongNamespace.HttpModules
{
    public class CustomHeaderModule : IHttpModule
    {
        public void Init(HttpApplication application)
        {
            application.PostReleaseRequestState += new EventHandler(application_PostReleaseRequestState);
        }

        public void Dispose()
        {
        }

        void application_PostReleaseRequestState(object sender, EventArgs e)
        {
            if (HttpContext.Current.Request.Url.ToString().ToLower().Contains(".svc") 
                && !HttpContext.Current.Request.Url.ToString().ToLower().Contains("authenticationservice.svc")))
            {
                var referrer = HttpContext.Current.Request.UrlReferrer;
                if (referrer == null)
                    throw new Exception("Not allowed to access this data"); 
                else if (referrer.Host != HttpContext.Current.Request.Url.Host)
                    throw new Exception("Not allowed to access this data"); 
            } 
        }
         
    }
}

The above sample will block any calls to the .svc endpoints (your OData endpoints that expose your data) if the call is not made from a site within the same domain.

This hasn’t been production tested yet (and honestly you’ll probably need to customize the business rules a bit) but at first sight seems not to interfere with the LS desktop (OOB or inB) or HTML client, but do blocking any other calls.

It’s not really ‘web-friendly’ either, in production code I’d suggest rewriting the response to a 403-forbidden instead. But then again who gives a fuck about http status codes… (*grabs popcorn*)

 

Keep rocking LS!
Jan