Possible to execute certain in-process calls without a session?

I’m in the process of redesigning a ServiceStack-based API and web app to solve a response-time problem with requests from Twilio.

Right now the app is hosted on Azure with SQL Server persistence and a Redis cache. However, very frequently (once a week) Azure has some sort of slowdown or issue accessing the SQL Server, and requests exceed Twilio’s 15-second timeout. Right now we are pushing these timed-out requests to a second instance of the app (including SQL and Redis), but that “solution” creates replication and synchronization complexity that we want to avoid.

Twilio supports request authentication to guarantee that a request is coming from their servers. Given that, I’m looking to simplify this part of the application by skipping the ServiceStack authentication process, but only for this part of the app. The publicly-accessible web UI and web API still require authentication. My desire is to have this part of the app be able to quickly access cached data for the Twilio interaction, then publish a command to a service bus that will be picked up for writes to the DB.

Is this sort of design supported in ServiceStack? Or would this be using the framework in a way that wasn’t intended? My alternative is to have that portion of the app be non-ServiceStack and manage caching on my own.

I don’t see an issue with calling a Service without requiring authentication but how are you going to validate that the request is from Twilio?

Twilio has an authentication process they use that essentially uses the API key associated with that account (see https://www.twilio.com/docs/api/security#validating-requests).

Granted I could have the service not require authentication, but how would I require authentication from one channel (web UI and web API) but not from another channel (my Twilio controller)?

That’s why I’m asking how are you going to validate if it’s a Twilio request? It seems like you just want a separate Service/entry point to validate Twilio requests then call an internal Service using the Service Gateway. Internal Service Requests don’t execute Global Filters or class-level [Authenticate] filter attributes so you can implement it that way where the Twilio request bypasses the [Authenticate] filter to call the same Service that’s requires authentication when calling it externally.

That did it. I’ll plan on using Gateway.Send for these internal calls then hide them in the public API with the [Restrict(VisibilityTo = RequestAttributes.None)] attribute.

1 Like