tourniquet Wiki & Documentation Rss Feed

Updated Wiki: Home

jfollas — Sat, 27 Dec 2008 16:56:33 GMT

Stop the Bleeding!

Project Description
Tourniquet is a personal caching proxy for Twitter. Client applications access Tourniquet in the same way that the Twitter API itself would be accessed by the application. Tourniquet caches the data received from Twitter in its own persistance layer, and is able to serve up cached data when the live API is down. This same thought process is also applied to outbound tweets and direct messages: Tourniquet will store the message and forward it to Twitter when the API is available. Because Tourniquet is a personally-hosted solution, there are no Twitter-imposed API hourly usage limits for accessing cached data.

Status
Tourniquet is in its first release development cycle, which is largely a prototype/proof of concept. Features and interfaces are subject to change as code is written, tested, and refactored.

Requirements
This iteration of Tourniquet is an ASP.NET 2.0 web application, and must be hosted on a web server. It uses its own built-in HTTP Basic Authentication mechanism, so the web server must grant ONLY anonymous access to the web application. For example, in the IIS properties for the application, uncheck Basic, Digest, and Integrated Security or else the custom authentication will not work (i.e., IIS will try to authenticate the supplied credentials using OS-level security before Tourniquet gets control of the page lifecycle).

To use the URL Rewriting functionality, ASP.NET must be mapped to handle .xml files (and optionally to .json, .rss, and .atom as well, if you want to pass requests in these formats through Tourniquet, though they will not be parsed or cached).

Tourniquet implements its persistance layer using a Provider model so that any type of back-end data store can eventually be used. The only provider that is currently available is one based on ADO.NET and SQL Server. As such, access to a SQL Server database is required. A SQL Server 2005 Express database is included.

Considerations for Using Tourniquet with Twitter Client Applications
List of Twitter clients known to work with Tourniquet

Tourniquet's primary design goal was to allow existing Twitter clients to access the Tourniquet application as if it were Twitter's actual server. The mechanism that Tourniquet uses to provide this pass-through functionality is URL Rewriting (using UrlRewriter.NET). This works by ASP.NET intercepting the web request for an .xml file and changing the URL to ~/proxy.aspx?command=... instead.

The caveat here is that the Twitter client application must allow the user to configure the Twitter server address that is used by the application (so instead of http://twitter.com/, the user must be able to specify something like http://theirdomain.com/tourniquet/).

When the user sends a tweet or direct message, Tourniquet will perform a store-and-forward operation. This is useful because messages will not get lost if the Twitter API is unavailable (Tourniquet will just hold on to it until the server is back up, and then will send the message at that time). One thing to be aware of is that a "fake status" will be returned by Tourniquet to indicate that the "store" operation was successful. This is nearly equivalent to the actual status that Twitter would have returned, except that the status's ID will be set to -1 and the source will say "QUEUED (NOT LIVE YET)". The actual status will appear in the timeline after the "forward" operation takes place.

Roadmap

Administration

Authentication

Updated Wiki: Authentication

jfollas — Mon, 18 Aug 2008 13:16:32 GMT

Twitter uses HTTP Basic authentication as its primary (only?) authentication method. In order to provide transparent access to Twitter, Tourniquet has adopted Basic authentication as well.

However, this isn't your grandfather's Basic authentication, which has typically been handled automatically by IIS (using the operating system's security database). Tourniquet needs to handle all authentication and authorization itself, so a custom HttpModule is included.

When Tourniquet needs the user credentials to be provided, it will return a 401 status code for the current request. The user will then be prompted to provide a username or password, and the request will be submitted with the credentials embedded in the header (Note: this is all automated by the Twitter client application). If IIS is not configured for pure anonymous access, then it will try to authenticate the new request itself before it enters the ASP.NET pipeline. For this reason, all authentication types (Basic, Digest, Integrated Security, etc) must be disabled in the IIS properties for the web application.

Once IIS is configured correctly, and the new request bearing the user credentials is received by Tourniquet, a couple of things will occur.

1. If the username is Admin, the password is checked to see if it matches what was configured in the web.config. If the password is still "Change Me", then access will be denied (resulting in another 401 being returned).

2. Tourniquet will first try to validate regular users against the Twitter API (/account/verify_credentials.xml). If Twitter denies, then a 401 is returned, otherwise the user is authenticated and a 1-way SHA1 hash of the password is saved to the database.

3. If Twitter is down, then a hash of the password is compared against a cached hash of the password stored in the database to see if the user had ever been successfully authenticated with this password before.

4. The default case is when the user is not "admin", Twitter is down, and the user had not been seen before. In this case, whatever password the user provided will be accepted. The user has to be explicitly allowed (in the web.config) before Tourniquet will allow them to do anything, and in the worst case, Twitter will simply reject the request if the password is bad. So, this is considered to be a low security risk.

Updated Wiki: Authentication

jfollas — Mon, 18 Aug 2008 13:14:13 GMT

Twitter uses HTTP Basic authentication as its primary (only?) authentication method. In order to provide transparent access to Twitter, Tourniquet has adopted Basic authentication as well.

However, this isn't your grandfather's Basic authentication, which has typically been handled automatically by IIS (using the operating system's security database). Tourniquet needs to handle all authentication and authorization itself, so a custom HttpModule is included.

When Tourniquet needs the user credentials to be provided, it will return a 401 status code for the current request. The user will then be prompted to provide a username or password, and the request will be submitted with the credentials embedded in the header (Note: this is all automated by the Twitter client application). If IIS is not configured for pure anonymous access, then it will try to authenticate the new request itself before it enters the ASP.NET pipeline. For this reason, all authentication types (Basic, Digest, Integrated Security, etc) must be disabled in the IIS properties for the web application.

Once IIS is configured correctly, and the new request bearing the user credentials is received by Tourniquet, a couple of things will occur.

1. If the username is Admin, the password is checked to see if it matches what was configured in the web.config. If the password is still "Change Me", then access will be denied (resulting in another 401 being returned).

2. Tourniquet will first try to validate regular users against the Twitter API (/account/verify_credentials.xml). If Twitter denies, then a 401 is returned, otherwise the user is authenticated and a 1-way SHA1 hash of the password is saved to the database.

3. If Twitter is down, then a hash of the password is compared against a cached hash of the password stored in the database to see if the user had ever been successfully authenticated with this password before.

4. The default case is when the user is not "admin", Twitter is down, and the user had not been seen before. In this case, whatever password was provided will be accepted. The user has to be explicitly allowed (in the web.config) before Tourniquet will allow them to do anything, and in the worst case, Twitter will simply reject the request if the password is bad. So, this is considered to be a low security risk.

Updated Wiki: Home

jfollas — Mon, 18 Aug 2008 12:54:50 GMT

Stop the Bleeding!

Project Description
Tourniquet is a personal caching proxy for Twitter. Client applications access Tourniquet in the same way that the Twitter API itself would be accessed by the application. Tourniquet caches the data received from Twitter in its own persistance layer, and is able to serve up cached data when the live API is down. This same thought process is also applied to outbound tweets and direct messages: Tourniquet will store the message and forward it to Twitter when the API is available. Because Tourniquet is a personally-hosted solution, there are no Twitter-imposed API hourly usage limits for accessing cached data.

Status
Tourniquet is in its first release development cycle, which is largely a prototype/proof of concept. Features and interfaces are subject to change as code is written, tested, and refactored.

Requirements
This iteration of Tourniquet is an ASP.NET 2.0 web application, and must be hosted on a web server. It uses its own built-in HTTP Basic Authentication mechanism, so the web server must grant ONLY anonymous access to the web application. For example, in the IIS properties for the application, uncheck Basic, Digest, and Integrated Security or else the custom authentication will not work (i.e., IIS will try to authenticate the supplied credentials using OS-level security before Tourniquet gets control of the page lifecycle).

To use the URL Rewriting functionality, ASP.NET must be mapped to handle .xml files (and optionally to .json, .rss, and .atom as well, if you want to pass requests in these formats through Tourniquet, though they will not be parsed or cached).

Tourniquet implements its persistance layer using a Provider model so that any type of back-end data store can eventually be used. The only provider that is currently available is one based on ADO.NET and SQL Server. As such, access to a SQL Server database is required.

Considerations for Using Tourniquet with Twitter Client Applications
List of Twitter clients known to work with Tourniquet

Tourniquet's primary design goal was to allow existing Twitter clients to access the Tourniquet application as if it were Twitter's actual server. The mechanism that Tourniquet uses to provide this pass-through functionality is URL Rewriting (using UrlRewriter.NET). This works by ASP.NET intercepting the web request for an .xml file and changing the URL to ~/proxy.aspx?command=... instead.

The caveat here is that the Twitter client application must allow the user to configure the Twitter server address that is used by the application (so instead of http://twitter.com/, the user must be able to specify something like http://theirdomain.com/tourniquet/).

When the user sends a tweet or direct message, Tourniquet will perform a store-and-forward operation. This is useful because messages will not get lost if the Twitter API is unavailable (Tourniquet will just hold on to it until the server is back up, and then will send the message at that time). One thing to be aware of is that a "fake status" will be returned by Tourniquet to indicate that the "store" operation was successful. This is nearly equivalent to the actual status that Twitter would have returned, except that the status's ID will be set to -1 and the source will say "QUEUED (NOT LIVE YET)". The actual status will appear in the timeline after the "forward" operation takes place.

Roadmap

Administration

Authentication

Updated Wiki: Administration

jfollas — Mon, 18 Aug 2008 12:49:01 GMT

As part of installing Tourniquet onto your web server, you should have edited the web.config file and set the Admin.Password appSetting. By default, this contains a value of "Change Me", which will not be accepted by Tourniquet. You should have also added "admin" to the <allow user=""> list, which is a comma-delimited list of users that are permitted to access Tourniquet. Regular user credentials will be verified against Twitter, but the "admin" user is used only for connecting to the admin site (i.e., it cannot access Twitter).

To access the Tourniquet administration website, simply open the following URL on your server:

http://{ your server name }/{ path to Tourniquet }/Admin

When prompted for credentials, enter "admin" as the username, and the password that you set in web.config.

Admin Menu
On all of the admin screens, clicking on the Tourniquet logo will return you to the admin menu.

Database Statistics
Shows how many statuses (tweets) and how many users have been saved to the database. Nice way to check that autofetching is working.

Autofetch
Used for setting up repeating commands, like fetching your friends timeline every 10 minutes, etc. Check a row, specify an optional start time and repeat frequency, enter your Twitter username/password, and then click Save. Note that any existing autofetches will be deleted, making what you save on this screen become the master list.

Updated Wiki: Administration

jfollas — Mon, 18 Aug 2008 12:48:46 GMT

Updated Wiki: Administration

jfollas — Mon, 18 Aug 2008 12:47:58 GMT

As part of installing Tourniquet onto your web server, you should have edited the web.config file and set the Admin.Password appSetting. By default, this contains a value of "Change Me", which will not be accepted by Tourniquet. You should have also added "admin" to the <allow user=""> list, which is a comma-delimited list of users that are permitted to access Tourniquet. Regular user credentials will be verified against Twitter, but the "admin" user is used only for connecting to the admin site (i.e., it cannot access Twitter).

To access the Tourniquet administration website, simply open the following URL on your server:

http://{ your server name }/{ path to Tourniquet }/Admin

When prompted for credentials, enter "admin" as the username, and the password that you set in web.config.

Admin Menu

DB Stats
Shows how many statuses (tweets) and how many users have been saved to the database. Nice way to check that autofetching is working.

Autofetch
Used for setting up repeating commands, like fetching your friends timeline every 10 minutes, etc. Check a row, specify an optional start time and repeat frequency, enter your Twitter username/password, and then click Save. Note that any existing autofetches will be deleted, making what you save on this screen become the master list.

Updated Wiki: Administration

jfollas — Mon, 18 Aug 2008 12:43:36 GMT

Updated Wiki: Administration

jfollas — Mon, 18 Aug 2008 12:42:06 GMT

Updated Wiki: Home

jfollas — Mon, 18 Aug 2008 12:32:30 GMT

Stop the Bleeding!

Project Description
Tourniquet is a personal caching proxy for Twitter. Client applications access Tourniquet in the same way that the Twitter API itself would be accessed by the application. Tourniquet caches the data received from Twitter in its own persistance layer, and is able to serve up cached data when the live API is down. This same thought process is also applied to outbound tweets and direct messages: Tourniquet will store the message and forward it to Twitter when the API is available. Because Tourniquet is a personally-hosted solution, there are no Twitter-imposed API hourly usage limits for accessing cached data.

Status
Tourniquet is in its first release development cycle, which is largely a prototype/proof of concept. Features and interfaces are subject to change as code is written, tested, and refactored.

Requirements
This iteration of Tourniquet is an ASP.NET 2.0 web application, and must be hosted on a web server. It uses its own built-in HTTP Basic Authentication mechanism, so the web server must grant ONLY anonymous access to the web application. For example, in the IIS properties for the application, uncheck Basic, Digest, and Integrated Security or else the custom authentication will not work (i.e., IIS will try to authenticate the supplied credentials using OS-level security before Tourniquet gets control of the page lifecycle).

To use the URL Rewriting functionality, ASP.NET must be mapped to handle .xml files (and optionally to .json, .rss, and .atom as well, if you want to pass requests in these formats through Tourniquet, though they will not be parsed or cached).

Tourniquet implements its persistance layer using a Provider model so that any type of back-end data store can eventually be used. The only provider that is currently available is one based on ADO.NET and SQL Server. As such, access to a SQL Server database is required.

Considerations for Using Tourniquet with Twitter Client Applications
List of Twitter clients known to work with Tourniquet

Tourniquet's primary design goal was to allow existing Twitter clients to access the Tourniquet application as if it were Twitter's actual server. The mechanism that Tourniquet uses to provide this pass-through functionality is URL Rewriting (using UrlRewriter.NET). This works by ASP.NET intercepting the web request for an .xml file and changing the URL to ~/proxy.aspx?command=... instead.

The caveat here is that the Twitter client application must allow the user to configure the Twitter server address that is used by the application (so instead of http://twitter.com/, the user must be able to specify something like http://theirdomain.com/tourniquet/).

When the user sends a tweet or direct message, Tourniquet will perform a store-and-forward operation. This is useful because messages will not get lost if the Twitter API is unavailable (Tourniquet will just hold on to it until the server is back up, and then will send the message at that time). One thing to be aware of is that a "fake status" will be returned by Tourniquet to indicate that the "store" operation was successful. This is nearly equivalent to the actual status that Twitter would have returned, except that the status's ID will be set to -1 and the source will say "QUEUED (NOT LIVE YET)". The actual status will appear in the timeline after the "forward" operation takes place.

Roadmap

Administration