wwCallbackHandler Security

There's no explicit support for security at the handler level for wwCallbackHandler. This means that if you need to secure access to your service handler you will need to use one of ASP.NET's security mechanisms to secure the service or build explicit authentication into your service itself.

Note that your ASP.NET server side code in the Callback methods has access to the security principle (HttpContext.Current.User) so your code can validate authentication as needed as long as the IIS/ASP.NET security is in place.

Page Security Context in AJAX calls

Typically the service handler will be called as part of inline AJAX requests from pages and in those scenarios the service request inherits the security context of the page. In many situations this security context is sufficient - for example once you are in an authenticated part of the Web site AJAX calls just work against a secured service because the user is the same as the logged in Web browser. So if you have Windows or Forms security set in a directory of your application the authentication automatically is passed on to the service AJAX call with the same credentials.

Explicit Access

If you have explicit external access (ie. cross domain or pure REST access from other applications) you may not be able to take advantage of existing Page security and so you will need to have your client authenticate the raw HTTP requests (ie. set the Principle with HttpWebRequest etc.). Again security for the server will have to be configured at the server level either with Windows Security on the service resource (ie. an .ASHX file) or by using an explict authentication scheme as part of the request (ie. pass username and password or an assigned token after an initial login).

Security Modes

You have few choices for securing services, which basically are the typical set of options you have with ASP.NET and Authentication:

  Last Updated: 12/29/2007 | © West Wind Technologies, 2008