It’s possible to run Quicksilver and ServiceAPI on a same site, with some modifications, as I blogged here. However, if you go down that path, there is something you must keep in mind: They are not using the same authentication mechanism.
I’ve seen issues where Quicksilver implementations have some WebAPI controllers, which were working fine until ServiceAPI is installed. The controllers started returning null for CustomerContext.Current.CustomerContact, and so on, breaking some functionalities. It’s bad, yes, but it happens because of reasons.
Quicksilver, by default, use cookie authentication. ServiceAPI, in other hands, uses bearer token authentication, and also disables the cookie authentication on WebAPI. In its Initialization module, ServiceAPI calls this:
GlobalConfiguration.Configure(config => { config.SuppressDefaultHostAuthentication(); });which suppresses the cookie authentication, and that CAN’T be overridden – meaning there is no way to enable cookie authentication for WebAPI controllers with Quicksilver. The reason for that? Well, to avoid CSRF – as my colleague Mark Hall explained here.
Once you installed ServiceAPI, your authentication cookie (which was set when an user logs in to Quicksilver) is no longer sent to WebAPI controllers, so those controllers will see those requests as unauthenticated. The MVC Controllers (which are used for default features in Quicksilver) still use authentication cookie, so they will continue to work as normal.
Therefore, if you install ServiceAPI on Quicksilver, you will have to choose between two options:
- Do not use WebAPI controllers in your website – stick with MVC Controllers which should be working fine.
- Explicitly send the authentication bearer to the WebAPI controllers. This can complicate things in client site.
Another alternative is to having ServiceAPI and Quicksilver in separate sites, but then that would be beside the point, right?
Hi Quan
Thanks for taking the time to share this. Really appreciate your help on this weird issue.
Do not use WebAPI controllers in your website – Ha, is that even possible in nowadays development?
Explicitly send the authentication bearer to the WebAPI controllers – Does it mean we have to manage bearer token for each user?
We chose the alternative anyway. However, it requires additional license ^_^
According to Mark Hall explanation, there is another option if the above mentioned alternative is not an affordable solution. Just simply remove the passive authentication middleware, it should be working.
Suggestion: Can Epi make the SuppressDefaultHostAuthentication configurable in Service Api?
I’d say probably no. It was there for a reason and we would not want it to be override-able.
Btw – the MVC controllers work very well in Quicksilver. If you are using the controllers for C in MVC, then it should be no problem. But if you want to have some RESTful APIs built on WebAPI, then it’s another story.
I like MVC controllers approach, definitely will use this approach in the next project if possible.