Creating a by site license (Algorithm)

I would like to provide as service, XML feeds to website owners. The XML file itself will be provided via a webservice (.asmx)

The problem is that the client may distribute the XML feed link, freely.

So i thought creating a "by Site license". The website owner-client will acknowledge me the websites that will request the XML feeds. With this way the XML feeds will be provided to specific http requests.

P.S. I know that you can change the headers and so开发者_如何学C on... But i would like to implement a solution "to slow things down" and feel better!

Could you please provide a better license algorithm? How could i secure the XML feeds from being distributed freely?

---

It entirely depends on what your business rules dictate; the more security you want, the more burden you place on individual sites to authenticate themselves. The easier you want it for client sites, the less complex your algorithm.

But basically, guard the content with a seat-specific token (i.e., password).

For each allowed client, you generate a token. You require seats to pass up that token as part of their request. When you receive that token, validate it (to whatever extent you deem appropriate) -- maybe you just check that it's a valid token, maybe you check the IP originator, maybe the token is part of a challenge-response encryption phase.

Track seat logins and look for abuse (requests coming from different IP addresses, requests coming in at high rates, etc.).

At the level of a startup service, you probably will not need much sophistication unless you are dealing with sensitive information or until you get successful.

---

You could use a solution based on certificates (PKI infrastructure): you create your own certificates that you send to your customers (each customer gets his own), and check it using a server side logic similar to what's described here: ASP.NET WebForms : Implementing PKI Authentication. It's not an ASMX example, but the Http Module logic is the same.

The advantage is users will not have to enter any password, as their browser should be able to present the certificate if requested by the site.

Of course, users can still copy and send certificates to other users, so you will still need some monitoring mechanism, based on the IP address for example (even if it's not 100% fullproof, it's better than nothing). Once you have detected a certificate seems dead (used by too many persons), you can mark it as non valid on your server for example, and send a new one to the legitimate user.

---

I have a license system close to that, I want to provide access to the service for specific XSL files and specific web pages, as it processes the xsl based on the tagsouped http from the url, To do this i have taken the referer url and compared to the allowed url, along with the xsl file requested

Another system i worked on took it one step further, and had the stream id (it was for video streaming) the user id and the time of day as the key sent in and if they matched then the stream was permitted (with a 1 minute window) to start.

But all of these methods work on knowing the order of parameters in the key and a hidden key sent in one or both directions and md5 hashing the resultant string for the visible / transmitted key.