Transcript Tapir User Manager

Tapir User Manager
Paul Houle, Library Systems, CU Library
http://www.honeylocust.com/x/products/tum/
[email protected]
TUM Features
• Cookie-based authentication
• Optional self-registration
• w/ e-mail address verification
• Automatic password resets
• Simple to integrate into existing applications
• Supports PHP and Perl applications
• Advanced Administrative Interface
• Add or Update User Records
• Real-time graphing
• E-mail sending to users
Why not Apache auth?
Apache’s authentication is integrated with the
web server, BUT:
•Users can’t log out
• No support for permanent login
• No automatic password reset
• Password file must be edited by hand
Web Portals
A web portal is a collection of web applications
that share:
• Common visual appearance
• A single user database
User management is necessary for administrative
screens, community, e-commerce, content
management, etc.
The web software crisis
Two kinds of open-source and commercial web
software:
• Frameworks
• Provide user management, templating, and
other services, BUT
• Have a high-learning curve and almost
always do something seriously wrong.
• Applications
• Many excellent apps exist, but since there’s
no standard, they don’t share a user database.
So we re-invent the wheel for every site…
Performance Goals
Appropriate for small to large sites:
• PHP/MySQL combination is easy to install and
maintain
• Supports > 1 M hits/day
• Doesn’t need to hit database to authenticate
• Supports > 1 M users
• Supports horizontal scaling
Experience: TUM exceeds above goals.
What it doesn’t do
It’s important to guarantee performance and
reliability, so:
• We don’t support other databases
• We don’t support other user database backends, i.e.
• LDAP
• Web services
Integration with outside services, for better or
worse, is by copying information.
• No (intrinsic) defense against packet sniffing.
Toolset
Based on market-leading tools for top
performance, reliability and maintainability:
•Apache 2 web server
• PHP 4 (transitioning to 5)
• MySQL 4.0 (transitioning to 4.1)
Secondary tools:
• Smarty templating system
• jpGraph (real-time graphing)
Programmers Eye View
require_once “tapir_auth.php”;
$auth=new Tapir_Auth();
// For personalization…
$auth->optional();
// To control access..
$auth->required();
$email=$auth->get_email();
$first_name=$auth->get_first_name();
Authentication Object
$auth->required() and related functions are about
200 lines of code in most languages.
By implementing the ‘Tapir_Auth’ object in a
language (say Java, TCL), applications written in
that language can use TUM authentication and
benefit from the TUM UI written in PHP.
Applications have the full power of SQL to access
the user db.
TUM is based on open standards (cookies, SQL) and
avoids roach motels (session-variable facilities and
proprietary object databases.)
Database access
Supports a single database connection per script,
lazy connection creation, interoperation with
other MySQL APIs, robust error handling and
convenience:
$count=
$auth->conn->select_scalar(
“SELECT COUNT(*) FROM tapir_users”)
Session Cookies
Based on “Do’s and Don’ts of Client Authentication on the Web”
http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf
398927:1:132.236.212.35:1097859122:15:oQjG5oe2T6uMmlvHyS7CnBte/d4
Session Id
Ip address
Capabilities
Timestamp
User Id
Cryptographic Hash
Cookies are reissued when timestamp is > 10 m
old. SHA1 hash with secret protects cookie from
forgery or alteration.
Other Cookies
tapir_permanent:
Secret token for permanent login like
Amazon, Yahoo.
tapir_browser:
Standard cookie issued by Apache’s
mod_usertrack to track browsers
If we add SSL support, we’ll also add a
tapir_secure cookie that only travels over SSL.
Customization
• A site can provide templates (plain PHP or smarty) for
both the user and admin pages
• Namespace conventions allow sites to add own tables
and columns to tapir_ tables
• Numerous hooks provided to allow modification of
login and registration behavior (can replace forms, talk
to external systems, etc.)
• Much of the admin UI is table-driven, much
customization is almost trivial.
• Configuration management system lets local sites
replace files, and configure PHP, Perl and Apache
configuration files with M4 macros
External User Interface
UI: Devil in the Details
• Jacob Nielsen:
• Authentication is a major barrier to usability
• Many processes on commercial web sites have
<50% success rate
•With Tivejo, we increased the registration success rate
from 60% to 85%, arXiv attains nearly 95%
•Base 32t coding for (e-mail verification, password reset,
and other) tokens: 60-bit security in 12 easy-to-type
characters, insensitive to case and common errors such
as 0/O and 1/L confusion
K8TLTI-78FKTR
Administrative Interface
•Benefits from development for multiple projects
•Tour: (arXiv.org)
• Main screen
• Advanced Search
• User detail screen
• Real-time graphing
UI Toolkit
• Purposely set out NOT to develop a universal
framework, BUT
• developing a sophisticated UI that’s consistent
and maintainable has required us to develop a
framework
• the “update protocol”
• template system
• the “screen” concept
• query builder
• real-time graphing
Case Study: Tivejo
• For a while, Brazil’s #1 voice chat service;
250,000+ users and 300,000 hits per day
• Web site controlled access to a Windows
application, interacted with Paltalk.com via a
‘REST’ web service
UDP, peer-to-peer, “VoIP”
browser
registers
chat client
authentication, call setup
downloads
Tivejo www
other user
web service
Paltalk.com
Tivejo mail
Tivejo db
Case Study: LS Wikis
Wanted a wiki for both public and private
documentation – existing wiki software didn’t
support authentication.
• Ported TUM to Solaris (install scripts)
• Two wikis:
•funkenstein: open registration
•docs-production: closed registration
• Chose PHP Wiki: Wiki Tiki Tavi
• About an hour to get authentication minimally
working.
• Another two days to get everything right
Case Study: arXiv.org
World’s largest physics publisher: (also math, cs…)
•293,000+ papers (nearly 200 submissions/day)
•60,000+ registered users
Legacy System:
Perl CGI scripts, using filesystem for paper
storage and Berkeley DB for user database. Very
messy data, some users aren’t even registered, not
possible to determine submitter of all papers
Requirement:
Flexible user database so we can implement
“endorsements” to control problem submissions.
Case Study: arXiv.org II
Challenges:
• Implement Perl Auth object for legacy scripts
• Clean up user database as best possible
• Making a complex user interface for
endorsement simple for users
• Making it easy for administrators to do routine
and not-so-routine jobs
Still to do:
• Move all admin functions to web
• Move e-mail subscriptions to web
• Require Password option, hide .PHP urls, etc.
Conclusion
TUM: Best-of-breed user management system, works with
(not against) existing applications and mainstream programming methods; incorporates lessons learned from a number of
projects; provides the interface that users expect from major
commercial sites; convenient to install and administer.
http://www.honeylocust.com/x/products/tum/