views:

64

answers:

2

Say, for example, you are caching data within your ASP.NET web app that isn't often updated. You have another process running outside of the app which ocassionally updates this data, when you do this you would like the cached data to be cleared immediately so that the next request picks up the new data straight away.

The caching service is running in the context of your web app and not externally - what is a good method of calling into the web app to get it to update the cache?

You could of course, just hack a page or web service together called ClearTheCache that does it. This can then be called by your other process. Of course you don't want this process to be externally useable or visible on your web app, so perhaps you could then check that incoming requests to this page are calling localhost, if not throw a 404. Is this acceptable? Could this be spoofed at all (for instance if you used HttpApplication.Request.Url.Host)?

I can think of many different ways to go about this, mainly revolving around creating a page or web service and limiting requests to it somehow, but I'm not sure any are particularly elegant. Neither do I like the idea of the web app routinely polling out to another service to check if it needs to execute something, I'd really like a PUSH solution.

Note: The caching scenario is just an example, I could use out-of-process caching here if needed. The question is really concentrating on invoking code, for any given reason, within a web app externally but in a controlled context.

A: 

Hey,

Consider an external caching mechanism like EL's caching block, which would be available to both the web and the service, or a file to cache data to.

HTH.

Brian
+2  A: 

Don't worry about the limiting to localhost, you may want to push from a different server in future. Instead share a key (asymmetrical or symmetrical doesn't really matter) between the two, have the PUSH service encrypt a block of data (control data for example) and have the receiver decrypt. If the block decrypts correctly and the data is readable you can safely assume that only the service that was supposed to call you has and you can perform the required actions! Not the neatest solution, but allows you to scale beyond a single server.

EDIT

Having said that an asymmetrical key would be better, have the PUSH service hold the private part and the website the public part.

EDIT 2

Have the PUSH service put the date/time it generated the cipher text into the data block, then the client can be sure that a replay attack hasn't taken place by ensuring the date/time is within an acceptable time period (say a minute).

null loop
Nice idea, I didn't like the idea of the page being visible externally though, even if it was an unlinked URL. Though I could throw 404 if the data didn't decrypt, but this is probably being quite naughty with respect to how error codes should be used.
PirateKitten
Chucking the 404 for the wrong block is just peachy. You're telling the outside world "nothing to see here, move along".
null loop