Sunday, March 11, 2012

Locking down a webservice

Hello my friend,

A good way would be to have your private web service methods inspect 3 parameters on each request. The IP address of the caller, the username and password. IP addresses can be spoofed, but less people are likely to crack your username and password, especially if you run the web service over https. This is a good way to mix private and public web services on the same machine.

Kind regards

Scotty


The IP Address of the caller is not significant here. My site is open to both signed on users and guests. So I am not restricting anything by the client ID (which is what I get when I check during a call that I make in the javascript). Passing a username/password is not necessarily viable either as the javascript would be readable by anyone and therefore so would the username/password. Also I am not currently running over https (nor do I plan to for these portions of the site).

The bottom line is I have code that is being used internally via AJAX that I don't want to expose. It is being called via javascript so the methods and parameters are viewable to all. With the previous ATLAS preview release I was on, the webservices were only local so I coded everything in one big webservice for my simple convience. I am just looking at avoiding rewriting everything. The nearest solution I can see but can't get to work so far is to use EnablePageMethods and just have the calls static on the pages (however this would lead to a lot of duplicate code). Also my javascript is reused and is referenced by lots of pages so I am not even sure how that could work.


Perhaps you can use cookies.

Set a session cookie when users first visit your page. Look for this cookie in your web service call.

HTH


I tried that first actually. I set a session variable in the Session_Start method in Global.asax and checked that in my class constructor, however it appears my test page gets the session variable set when it makes the call. I also thought I could use the context.IsLocal check however that is from the browser page not the source page. I thought I could go after the source page itself from the URL but the URL reports my .asmx page.


Well here is what I came up with (hoping for the least amount of code rewriting).

Create a base class for all forms that use the Internal Webservice. Put all webservice methods in base class as public static WebMethods. Inherit from the base class for all forms using the webservices. Change the javascript to use "PageMethods" instead of the old webservice name.

I have no idea if this will work 100% but I think it accomplishes my goal of basically conitnuing to use AJAX while not exposing all of my webservice to the entire world.

Anyone see any problems with this approach?


I am using cookies currently. Somehow, the Session object is not available from web service call (i.e .asmx).

HTH



MikeLim:

I am using cookies currently. Somehow, the Session object is not available from web service call (i.e .asmx).

HTH?

Hi,
Actually,?Session is avaliable in web service.
Please refer to this: http://msdn2.microsoft.com/en-us/library/aa480509.aspx

ccarlinx:

Well here is what I came up with (hoping for the least amount of code rewriting).

Create a base class for all forms that use the Internal Webservice.? Put all webservice methods in base class as public static WebMethods.? Inherit from the base class for all forms using the webservices.? Change the javascript to use "PageMethods" instead of the old webservice name.?

?I have no idea if this will work 100% but I think it accomplishes my goal of basically conitnuing to use AJAX while not exposing all of my webservice to the entire world.?

?Anyone see any problems with this approach???

This is definitely a good idea to achieve your goal.

No comments:

Post a Comment