Home/ Questions/Q 335757
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T10:10:43+00:00

I’ve written a simple web service that converts a word doc to a pdf.

  • 0

I’ve written a simple web service that converts a word doc to a pdf. As part of the Convert method, it takes in a custom settings object that contains info about the doc path, etc. and a DataTable of, er, data.

I am now creating a “helper” class to consume the web service in order to remove the hassle for other developers and, if truth be told, control the consumers of the web service. I don’t want anyone diving into the web service (even a developer) and using it willy-nilly.

Let’s call my web service WordToPdfWS and my helper class WordToPdfHelper (ugh); WordToPDFHelper has a web reference to WordToPdfWS and can call the Convert(settings) method no problem (it even works!).

When I create a consumer / test app and set a reference to WordToPdfHelper, I find that (as expected) I can create the WordToPdfHelper object and use it as intended. BUT, in my consumer, I can also create my web service (WordToPdfWS) and call it directly – from my consumer!

This is definitely not what I want (e.g. any Tom, Dick and Harriet Developer being able to get at it), is there anyway to prevent it?

Kind regards,

Mike K.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Interesting problem. The ideal scenario is one where you limit access to the WS proxy stub within the lib, but can also use the auto-generated code. The auto-gen’d code just happens to produce its output as public, and updating that code file is undesirable.

    I believe you can find a solution by employing techniques for code access security. You can restrict code access using the Framework’s structure for cross-assembly calls.

    Implementing the code access security, whether it be on the class or method level, could be accomplished using a partial class that mirrors the auto-generated stub class (by namespace and name).

    Your stub class is already a partial class (assuming it was generated with Visual Studio). Creating a separate partial class file and employing code access security could theoretically provide the wrapper restriction you’re seeking, plus stay in lock-step with the internal web service stub while staying out of the way of future updates.

    I haven’t tried this, so your mileage may vary.

    • 0