Home/ Questions/Q 7405353
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T05:23:30+00:00

I’m writing a secure WCF REST webservice using C#. My code is something like

  • 0

I’m writing a secure WCF REST webservice using C#.

My code is something like this:

public class MyServiceAuthorizationManager : ServiceAuthorizationManager
{
    protected override bool CheckAccessCore(OperationContext operationContext)
    {
        base.CheckAccessCore(operationContext);

        var ctx = WebOperationContext.Current;
        var apikey = ctx.IncomingRequest.Headers[HttpRequestHeader.Authorization];
        var hash = ctx.IncomingRequest.Headers["Hash"];
        var datetime = ctx.IncomingRequest.Headers["DateTime"];
        ...

I use headers (Authorization,Hash,DateTime) to store informations about apikey, current datetime and the hashed request URL while request body contains only URL and webservice parameters.

Example:

http://127.0.0.1:8081/helloto/daniele

Is this the right way or I’ve to pass and retieve those parameters from URL like this:

http://127.0.0.1:8081/helloto/daniele&apikey=123&datetime=20120101&hash=ddjhgf764653ydhgdhgfjiutu56

are there differences between those two methods?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think both methods would work for simple cases. However, if you want to make maximum use of native HTTP behaviours, you should go with the headers approach, not the URL query parameters one.

    This will allow you to (for example) use HTTP response codes to indicate to client that a resource has been permanently moved (response code 301) so the client can automatically update links. If the URL included the authentication information, it is not clear to a client that two different URLs are actually referring to the same resource. In other redirect scenarios, the headers will be automatically included so you don’t have to worry about appending parameters to redirect URLs.

    Also, it should allow better caching behaviour on clients (if that is relevant in your scenario).

    As another example, using headers would allow you to authenticate a request based just on the headers without requiring the client to send the message body. The idea is that you authenticate with the headers, then send the client an HTTP 100 Continue response. The client should not send the message body until it gets the 100. This could be an important optimisation if you are doing POSTs or PUTs with large message bodies.

    There are other examples, but whether any given one is relevant depends on your scenarios and on the clients you expect to serve.

    In summary, I would say it is better to make use of elements of the protocol as they were explicitly intended – this gives you the best chance of behaving as a client expects and should make your service more accessible, efficient and usable in the longer term.

    • 0