Loading ...
Sorry, an error occurred while loading the content.

Tracking client-applications using User-Agent

Expand Messages
  • Jan Algermissen
    Hi, suppose, you expose a REST-API and want to keep track clients which you gave access to the API. Each client is given a client ID. Straight-forward solution
    Message 1 of 4 , Apr 3, 2013
    • 0 Attachment
      Hi,

      suppose, you expose a REST-API and want to keep track clients which you gave access to the API. Each client is given a client ID.

      Straight-forward solution would be to use the Authentication (think OAuth) header to extract the client ID.

      However, suppose there are some resource you do not want to protect to enable public caching.

      What about asking the client developers to put the client ID in the User-Agent header. Yes, they would not have to, but let's suppose they are closely enough associated to be reliable enough. If this occasionally slips, that's no big deal. It is for monitoring purposes only. No payment-per-ID or throttling involved.

      Do you have any thoughts or experiences doing something similar?

      Jan
    • Mike Kelly
      If the request hits a cache your origin server isn t going to see the request so how would that work? I think I would just stick to doing auth via the auth
      Message 2 of 4 , Apr 3, 2013
      • 0 Attachment

        If the request hits a cache your origin server isn't going to see the request so how would that work?

        I think I would just stick to doing auth via the auth header. But I might be missing something?

        Cheers,
        M

        On 3 Apr 2013 09:46, "Jan Algermissen" <jan.algermissen@...> wrote:
         

        Hi,

        suppose, you expose a REST-API and want to keep track clients which you gave access to the API. Each client is given a client ID.

        Straight-forward solution would be to use the Authentication (think OAuth) header to extract the client ID.

        However, suppose there are some resource you do not want to protect to enable public caching.

        What about asking the client developers to put the client ID in the User-Agent header. Yes, they would not have to, but let's suppose they are closely enough associated to be reliable enough. If this occasionally slips, that's no big deal. It is for monitoring purposes only. No payment-per-ID or throttling involved.

        Do you have any thoughts or experiences doing something similar?

        Jan

      • Jan Algermissen
        ... Ha! Classic facepalm.org . (Should say it was just a trick question...) Let s assume I control the cache because it is inside a large corporation. Yeah - I
        Message 3 of 4 , Apr 3, 2013
        • 0 Attachment
          On 03.04.2013, at 10:52, Mike Kelly <mikekelly321@...> wrote:

          > If the request hits a cache your origin server isn't going to see the request so how would that work?

          Ha! Classic facepalm.org . (Should say it was just a trick question...)


          Let's assume I control the cache because it is inside a large corporation.

          Yeah - I could offload the auth at that point, too. I know...

          Still curious.

          Jan


          >
          > I think I would just stick to doing auth via the auth header. But I might be missing something?
          >
          > Cheers,
          > M
          >
          > On 3 Apr 2013 09:46, "Jan Algermissen" <jan.algermissen@...> wrote:
          >
          > Hi,
          >
          > suppose, you expose a REST-API and want to keep track clients which you gave access to the API. Each client is given a client ID.
          >
          > Straight-forward solution would be to use the Authentication (think OAuth) header to extract the client ID.
          >
          > However, suppose there are some resource you do not want to protect to enable public caching.
          >
          > What about asking the client developers to put the client ID in the User-Agent header. Yes, they would not have to, but let's suppose they are closely enough associated to be reliable enough. If this occasionally slips, that's no big deal. It is for monitoring purposes only. No payment-per-ID or throttling involved.
          >
          > Do you have any thoughts or experiences doing something similar?
          >
          > Jan
          >
          >
        • Paul Cohen
          On Wed, Apr 3, 2013 at 10:45 AM, Jan Algermissen ... In my case we will have multiple installations of the same software clients accessing our API. My idea is
          Message 4 of 4 , Apr 3, 2013
          • 0 Attachment
            On Wed, Apr 3, 2013 at 10:45 AM, Jan Algermissen
            <jan.algermissen@...> wrote:
            >
            > suppose, you expose a REST-API and want to keep track clients which you gave access to the API. Each client is given a client ID.
            >
            > Straight-forward solution would be to use the Authentication (think OAuth) header to extract the client ID.
            >
            > However, suppose there are some resource you do not want to protect to enable public caching.
            >
            > What about asking the client developers to put the client ID in the User-Agent header. Yes, they would not have to, but let's suppose they are closely enough associated to be reliable enough. If this occasionally slips, that's no big deal. It is for monitoring purposes only. No payment-per-ID or throttling involved.
            >
            > Do you have any thoughts or experiences doing something similar?

            In my case we will have multiple installations of the same software
            clients accessing our API. My idea is to use User-Agent for
            identifying the software and its version but use Authentication header
            or possibly an application key passed as a query parameter to identify
            a specific client (instance or installation).

            It seems there are three types of client identity that can be relevant
            for an API to keep track of; software identity, software installation
            identity and end user identity. In my case we have no current use case
            where end user identity is required but we are interested in the first
            two types of client identity.

            /Paul

            --
            Paul Cohen
            www.seibostudios.se
            mobile: +46 730 787 035
            e-mail: paul.cohen@...
          Your message has been successfully submitted and would be delivered to recipients shortly.