User:Jpr@uab.edu/DocsBotCookbook

From UABgrid Documentation
(Difference between revisions)
Jump to: navigation, search
(Anatomy of a Bot: Thoughts on supporting bot login)
(Anatomy of a Bot: Break login discussion into new subsection Bot Operations)
 
Line 14: Line 14:
 
The enter Bot page can useful info to any project from the perspective of general project rules.  Make sure to also read the last section on programming languages just to make sure to have a good context for future background thought.  There are libraries for a number of popular development languages and platforms.
 
The enter Bot page can useful info to any project from the perspective of general project rules.  Make sure to also read the last section on programming languages just to make sure to have a good context for future background thought.  There are libraries for a number of popular development languages and platforms.
  
* [[wikipedia:Wikipedia:Creating_a_bot#Logging_in|Bot Login]]
+
== Bot Operations ==
  
The login section highlights what will need support on docs.  A bot typically uses a traditional user/password account on Mediwiki.  This won't work so well with our default SAML web-browser profile, since that favors human interactive users.  It shouldn't be difficult for us to support user/password bot accounts, and would be interesting to have those traveling across a client-authenticated SSL connection.  That would allow us to know who the (human) person is running the bot and allow for normal bot login-handshaking using the bot account method.
+
=== Login ===
 +
 
 +
The [[wikipedia:Wikipedia:Creating_a_bot#Logging_in|Bot Login]] section highlights what will need support on docs.  A bot typically uses a traditional user/password account on Mediwiki.  This won't work so well with our default SAML web-browser profile, since that favors human interactive users.  It shouldn't be difficult for us to support user/password bot accounts, and would be interesting to have those traveling across a client-authenticated SSL connection.  That would allow us to know who the (human) person is running the bot and allow for normal bot login-handshaking using the bot account method.
  
 
In other words, this wouldn't demand SSO or account coordination between Apache and Mediawiki.  Apache just does a client-auth'd SSL handshake and validates the user DN against our account database.  This happens just as part of connection establishment and is just an easy way of providing "login" accounting.  The bot work still takes place explicitly under a bot account for that specfic mediawiki instance.  The SSL channel also makes it possible to support proxy-certs for delegation to the bot.  This model also works for a large number of other tools and avoids us having to do much integration work aside from configuring Apache for ssl-auth in particular areas of the URL namespace.
 
In other words, this wouldn't demand SSO or account coordination between Apache and Mediawiki.  Apache just does a client-auth'd SSL handshake and validates the user DN against our account database.  This happens just as part of connection establishment and is just an easy way of providing "login" accounting.  The bot work still takes place explicitly under a bot account for that specfic mediawiki instance.  The SSL channel also makes it possible to support proxy-certs for delegation to the bot.  This model also works for a large number of other tools and avoids us having to do much integration work aside from configuring Apache for ssl-auth in particular areas of the URL namespace.

Latest revision as of 13:42, 24 February 2012

Writing bots for docs is for finding and writing information.

Some things to get started.

Contents

[edit] Anatomy of a Bot

Everything has an anatomy and bots are no different. If you want them to help you, you need to understand what makes them tick. The Creating a bot page give a good overview. To get a starting context, make sure you read:

The enter Bot page can useful info to any project from the perspective of general project rules. Make sure to also read the last section on programming languages just to make sure to have a good context for future background thought. There are libraries for a number of popular development languages and platforms.

[edit] Bot Operations

[edit] Login

The Bot Login section highlights what will need support on docs. A bot typically uses a traditional user/password account on Mediwiki. This won't work so well with our default SAML web-browser profile, since that favors human interactive users. It shouldn't be difficult for us to support user/password bot accounts, and would be interesting to have those traveling across a client-authenticated SSL connection. That would allow us to know who the (human) person is running the bot and allow for normal bot login-handshaking using the bot account method.

In other words, this wouldn't demand SSO or account coordination between Apache and Mediawiki. Apache just does a client-auth'd SSL handshake and validates the user DN against our account database. This happens just as part of connection establishment and is just an easy way of providing "login" accounting. The bot work still takes place explicitly under a bot account for that specfic mediawiki instance. The SSL channel also makes it possible to support proxy-certs for delegation to the bot. This model also works for a large number of other tools and avoids us having to do much integration work aside from configuring Apache for ssl-auth in particular areas of the URL namespace.

[edit] Development Tools

Among that more appealing developer APIs for mediawiki are the ones for perl, python, scheme and lisp.

[edit] CVS-like Command-line client

The Perl-based Mediawiki-Client looks like an interesting tool for building hooks because it exposes a command-line interface and is promoted as having a CVS-like feel.

[edit] Useful Existing Bots

There's already a lot of work in this space and some tools are designed to be generally helpful, like edit assitors.

[edit] AutoWikiBot

The AutoWikiBrowser bot is a mediawiki editor for windows that is designed to ease editing tasks. It looks interesting but it's possible our default config for authn on docs will make tools like this harder to use since our log in is not by user/pass. If it supports ssl auth then it's awesome. Otherwise something else woudl need to be done to support tools like this.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox