tournament 1.1.0 → 2.0.0

data/webgui/vendor/plugins/restful_authentication/lib/authorization.rb

@@ -0,0 +1,14 @@
+module Authorization
+  def self.included(recipient)
+    recipient.extend(ModelClassMethods)
+    recipient.class_eval do
+      include ModelInstanceMethods
+    end
+  end
+
+  module ModelClassMethods
+  end # class methods
+
+  module ModelInstanceMethods
+  end # instance methods
+end

data/webgui/vendor/plugins/restful_authentication/lib/trustification/email_validation.rb

@@ -0,0 +1,20 @@
+module Trustification
+  module EmailValidation
+    unless Object.constants.include? "CONSTANTS_DEFINED"
+      CONSTANTS_DEFINED = true # sorry for the C idiom
+    end
+    
+    def self.included(recipient)
+      recipient.extend(ClassMethods)
+      recipient.class_eval do
+        include InstanceMethods
+      end
+    end
+
+    module ClassMethods
+    end # class methods
+
+    module InstanceMethods
+    end # instance methods
+  end
+end

data/webgui/vendor/plugins/restful_authentication/lib/trustification.rb

@@ -0,0 +1,14 @@
+module Trustification
+  def self.included(recipient)
+    recipient.extend(ModelClassMethods)
+    recipient.class_eval do
+      include ModelInstanceMethods
+    end
+  end
+
+  module ModelClassMethods
+  end # class methods
+
+  module ModelInstanceMethods
+  end # instance methods
+end

data/webgui/vendor/plugins/restful_authentication/notes/AccessControl.txt

@@ -0,0 +1,2 @@
+
+See the notes in [[Authorization]]

data/webgui/vendor/plugins/restful_authentication/notes/Authentication.txt

@@ -0,0 +1,5 @@
+Guides to best practices:
+* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
+** specifically, of course, the chapter on Authentication.
+* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+* "Authentication and Identification,":http://www.downes.ca/post/12 by Stephen Downes **Highly Recommended**

data/webgui/vendor/plugins/restful_authentication/notes/Authorization.txt

@@ -0,0 +1,154 @@
+h2. Authorization
+
+"Best Practices for Authorization":http://www.owasp.org/index.php/Guide_to_Authorization
+# auth system should deny by default
+# Principle of least privilege (fine-grain)
+# each non-anonymous entry point have an access control check
+# authorization check at or near the beginning of code implementing sensitive activities
+# Ensure that Model code checks to ensure that the requesting user should have access to the protected resource.
+# Reauthorization for high value activities or after idle out
+# If custom code is required to perform authorization functions, consider
+  fail-safe authentication and exception handling – ensure that if an exception
+  is thrown, the user is logged out or at least prevented from accessing the
+  protected resource or function.
+# Well written applications centralize access control routines, so if any bugs
+  are found, they can be fixed once and the results apply throughout the
+  application immediately.
+
+h2. Authorization in a trust context
+
+* [http://en.wikipedia.org/wiki/Authorization]
+* remember: goal is **prediction** not **control**
+
+h2. Patterns for Policy definition / Authorization / access control
+
+*Reference Monitor (SecPatt p256)
+** Set of authorization rules
+** Actor, Action, Resource => Monitor+(rules) => ctrlr
+* Role based:
+   subj, role, right. action, resource
+  RBAC, access is controlled at the system level, outside of the user's control
+* Filter based
+  User x Controller x Action x Params --
+* Object based
+  model security delegation
+* Access Control Matrix http://en.wikipedia.org/wiki/Access_Control_Matrix
+* CommandProcessor pattern (DSL approach)
+* DENY FROM ... / ALLOW FROM ... approach
+* Capability based control: bundle together the designation of an object and the permission to access that object
+  ie. I can name it if and only if I am allowed to get at it.
+
+h2. Notes from "Security patterns":http://www.amazon.com/Security-Patterns-Integrating-Engineering-Software/dp/0470858842
+by M Schumacher ("website for book":http://www.securitypatterns.org/)
+
+Reference Monitor (SecPatt p256)
+ * Set of authorization rules
+ * Actor, Action, Resource  => Monitor+(rules) => ctrlr
+
+= Full access with Errors (SecPatt p305)
+
+* Users should not be able to view data or perform operations for which they
+  have no permissions.
+* Hiding an available and accessible function is inappropriate, because users
+  must be able to see what they can do.
+* The visual appeal and usability of a graphical user interface (GUI) can be de-
+  graded by varying layouts depending on the (current) access rights of a
+  user. For example, blank space might appear for some users where others see
+  options they can access, or sequence and number of menu items might differ,
+  depending on the current user’s rights, and thus ‘blind’ operation of the menu
+  by an expe- rienced user is no longer possible.
+* Showing currently unavailable functions can tease users to into upgrading
+  their access rights, for example by paying for the access or buying a license
+  after us- ing a demo version.
+* Trial and error are ineffective means of learning which functions are
+  accessible.  Invoking an operation only to learn that it doesn’t work with
+  your access rights is confusing.
+* The privilege grouping of the typical user community might not be known at the
+  design time of the GUI, and it might change over time, for example through
+  organizational or business process changes, so that providing a few special
+  modes of the GUI depending on the corresponding user roles is inappropriate.
+* Checking whether a function is allowed by a user is most efficient, robust and
+  secure, if done by the function itself—at least the code performing the checks
+  is then closely related to the code performing the subsequent operation
+  afterwards.
+
+h2. Outcomes / Obligations
+
+-- forbid
+-- ask for trust escalation (eg log in, prove_as_human, validate_email, are_you_sure, send_me_ten_cents)
+-- drag ass
+-- permit
+
+-- reinterpret past actions based on future evolution of trust
+-- prioritize changesets based on trust.
+
+
+h2. Notes from "Core Security Patterns":http://www.coresecuritypatterns.com/patterns.htm website
+
+# Authentication Enforcer 	who the hell are you
+# Intercepting Validator	Is your request well-formed
+# Authorization Enforcer  	Are you allowed to do that
+# Secure Logger 		Know what's happening/happened
+#
+
+h2. notes from "XACML":http://www.nsitonline.in/hemant/stuff/xacml/XACML%20Tutorial%20with%20a%20Use%20Case%20Scenario%20for%20Academic%20Institutions.htm
+
+PolicySets [Policy Combining Algorithm]
+Policy [Rule Combining Algorithm] (defines access to particular resources.)
+# Target
+## Subject Attributes
+## Resource Attributes
+## Action Attributes
+## Environment Attributes
+# Rule [Effect]		Identify various conditions or cases under which a policy may become applicable
+## Subject Attributes	user who has made an access request
+## Resource Attributes	object to which access is requested
+## Action Attributes	action the subject wants to take on the resource
+## Environment Attributes	request environment (time of day, ip, etc)
+## Conditions
+# Obligations
+
+Roles    -- student, janitor, dean, stranger, ...
+Branches -- Departments, etc.
+
+* Examine applicable rules until you get an outcome, failure or passes thru (in which case rejected)
+* Rule combining Algorithms
+
+* Obligations -- things to do once requests have been denied or permitted
+
+Reference Monitor (SecPatt p256)
+ * Set of authorization rules
+ * Actor, Action, Resource  --> Monitor+(rules) --> ctrlr
+
+#
+# ask for permissions on arbitrary (subject, action, resource)
+  * roles
+# get filtered object based on action (:public_info, :admin_info, etc.)
+# attach a rule to a (subject|role, action, resource) triple
+  "subject should have role R"
+  "subject should have role R on resource X"
+  "should meet the
+
+* Role supervisor:
+  * adds, defines, removes roles.  no policy -- just attaches roles to users
+
+* Policy
+  answers "can Actor do Action to Resource"
+  * Rules
+  * Rule resolution
+  * outcome, obligations.
+  policy definitions can come from many places, go to policy mgr.
+* Hall monitor
+  enforces policy (before filters)
+* Policy observers
+  handle policy obligations
+
+* Athentication   --  identification, really: securely attach visitor to identity
+* Validation      -- qualify trust
+* Access control  -- define policy
+** Roles
+** Acc. matrix
+* Authorization	-- enforce policy (reference monitor ; filter chain)
+* Obligations
+**  Audit 	-- (observer)
+

data/webgui/vendor/plugins/restful_authentication/notes/RailsPlugins.txt

@@ -0,0 +1,78 @@
+h1. Rails Authentication, Authorization and Access Control plugins
+
+h2. Authentication plugins
+
+* http://github.com/technoweenie/restful-authentication/tree/master -- the accepted standard for authentication
+* http://github.com/mrflip/restful-authentication/tree/master -- my fork of restful_authentication with more modularity, more specs and a few security tweaks
+* http://github.com/josh/open_id_authentication/tree/master -- OpenID authentication
+
+h2. Authorization plugins
+
+From
+* http://agilewebdevelopment.com/plugins/tag/security
+* http://www.vaporbase.com/postings/Authorization_in_Rails
+
+* http://github.com/jbarket/restful-authorization/tree/master
+
+* http://agilewebdevelopment.com/plugins/rolerequirement
+  http://code.google.com/p/rolerequirement/
+  http://rolerequirement.googlecode.com/svn/tags/role_requirement/
+  9 votes
+
+* http://github.com/ezmobius/acl_system2/
+  http://agilewebdevelopment.com/plugins/acl_system
+  http://opensvn.csie.org/ezra/rails/plugins/dev/acl_system2/
+  last touched 2006
+  57 votes on AWD
+  * also: http://agilewebdevelopment.com/plugins/acl_system2_ownership
+
+  bq. access_control [:new, :create, :update, :edit] => '(admin | user |
+                      moderator)', :delete => 'admin'
+      <% restrict_to "(admin | moderator) & !blacklist" do %>
+        <%= link_to "Admin & Moderator only link", :action =>'foo' %>
+      <% end %>
+
+* Authorization Recipe (from Rails Recipes #32)
+  http://www.vaporbase.com/postings/Authorization_in_Rails
+  http://opensvn.csie.org/mabs29/plugins/simple_access_control
+
+* Active ACL
+  http://phpgacl.sourceforge.net/demo/phpgacl/docs/manual.html
+  (Access-matrix driven)
+
+* http://github.com/aiwilliams/access_controlled_system
+
+* http://agilewebdevelopment.com/plugins/access
+
+* http://robzon.aenima.pl/2007/12/base-auth-is-out.html
+  http://agilewebdevelopment.com/plugins/base_auth
+  http://base-auth.googlecode.com/svn/trunk/
+  40 votes
+
+* http://agilewebdevelopment.com/plugins/authorization
+  http://www.writertopia.com/developers/authorization
+  http://github.com/DocSavage/rails-authorization-plugin/tree/master
+  Opaque policy descriptions
+  19 votes
+
+* http://github.com/shuber/access_control_list/
+  Not much there yet
+
+* https://opensvn.csie.org/traccgi/tobionrails
+  http://agilewebdevelopment.com/plugins/access_control
+  http://opensvn.csie.org/tobionrails/plugins/access_control
+  last touched 1 year ago
+
+* http://github.com/mdarby/restful_acl/
+  -- google code too --
+  Just does REST?  More of an app than a plugin.
+
+* http://github.com/stonean/lockdown/tree/master
+  http://lockdown.rubyforge.org
+  http://groups.google.com/group/stonean_lockdown?hl=en
+  "Lockdown stores an array of access rights in the session"
+
+h2. Trust / Validation etc. plugins
+
+
+* http://agilewebdevelopment.com/plugins/recaptcha

data/webgui/vendor/plugins/restful_authentication/notes/SecurityPatterns.txt

@@ -0,0 +1,163 @@
+h1. Security from the perspective of a community site.
+
+Better than anything you'll read below on the subject:
+
+* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
+* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+* "Core Security Patterns":http://www.coresecuritypatterns.com/patterns.htm
+* Stephen Downes' article on "Authentication and Identification":http://www.downes.ca/post/12
+
+h2. Snazzy Diagram
+
+!http://github.com/technoweenie/restful-authentication/tree/master/notes/SecurityFramework.png?raw=true!:http://github.com/technoweenie/restful-authentication/tree/master/notes/SecurityFramework.png
+
+(in notes/SecurityFramework.png)
+
+h2. Terms
+
+* Identification: Assign this visitor a name and an associated identity
+  (picture, website, favorite pokemon, trust metric, security roles).
+  
+  bq. "Behold. I am not Gandalf the Grey, whom you betrayed, I am Gandalf the White,
+  who has returned from death." -- Tolkien
+
+* Authentication: Verify this visitor matches the claimed identity.
+
+  bq. "My name is Werner Brandis. My voice is my password. Verify me." -- Sneakers
+
+* Authorization: Given a request (Actions+Resource+Environment), decide if it's safe.
+
+  bq. "Of every tree of the garden thou mayest freely eat: But of the tree of
+  the knowledge of good and evil, thou shalt not eat of it: for in the day that
+  thou eatest thereof thou shalt surely die." -- Gen 2:16-17
+  
+* Trust: Confidence this visitor will act reliably.
+  
+  bq. "A copper! A copper! How d'ya like that, boys? And we went for it. _I_ went
+  for it. Treated him like a kid brother. And I was gonna split fifty-fifty with
+  a copper." -- James Cagney, White Heat
+
+** Reputation from Trust Network: Award trust to this visitor based on what other trusted parties say.
+
+  bq. "He used my name? In the /street/?  He called me a punk? My name was on
+  the street? When we bounce from this s-t here, Y'all gonna go down on them
+  corners, let the people know: word did not get back to me. Let 'em know Marlo
+  step to any m-f-: Omar, Barksdale, whoever. My name IS my NAME." -- Marlo
+  Stansfield, The Wire (paraphrased)
+
+* Reputation from Past Actions:
+
+  bq. "The man you just killed was just released from prison. He could've f-in'
+  walked. All he had to do was say my dad's name, but he didn't; he kept his
+  f-ing mouth shut. And did his f-in' time, and he did it like a man. He did
+  four years for us.  So, Mr. Orange, you're tellin' me this very good friend of
+  mine, who did four years for my father, who in four years never made a deal,
+  no matter what they dangled in front of him, you're telling me that now, that
+  now this man is free, and we're making good on our commitment to him, he's
+  just gonna decide, out of the f-ing blue, to rip us off?" -- Nice Guy Eddie,
+  Reservoir Dogs
+
+* Access control
+  
+** Role
+  * http://en.wikipedia.org/wiki/Role-based_access_control
+  * "Role-Based Access Control FAQ":http://csrc.nist.gov/groups/SNS/rbac/faq.html
+  * "Role Based Access Control and Role Based Security":http://csrc.nist.gov/groups/SNS/rbac/ from the NIST Computer Security Division
+
+
+* Auditing & Recovery
+
+h2. Concept
+
+@  The below is a mixture of half-baked, foolish and incomplete. Just sos you know. @
+
+* Identity here will mean 'online presence' -- user account, basically.
+* Person will mean the remote endpoint -- whether that's a person or robot or
+  company.  (Security papers call this "Subject" but that's awful).
+* It's easy to confuse 'person' and 'identity', so easy I probably have below.
+
+Why do you need to authenticate?  For authorization. So traditionally, we think
+
+  person <- (ath'n token) <- identity <- (policy) <- actions
+
+That is, actions are attached to an identity by security policy, identity is
+attached to a person by their authentication token.
+
+The problem is that we cannot authenticate a /person/, only the token they
+present: password, ATM card+PIN number, etc.
+bq. "The Doors of Durin, Lord of Moria. Speak friend, and enter" -- Tolkien
+
+Anyone who presents that card+PIN, Elvish catchphrase, or voice print will be
+authenticated to act as the corresponding identity (account holder, friend of
+the elves, nerdy scientist), and we have no control over those tokens.
+
+  person <- (ath'n token) <- identity <- (az'n policy) <- actions
+        ^^^^ This step is wrong.
+
+The solution is to not care, or rather to reframe our goals.
+
+What we actually want is not to /control/ users' actions, but to /predict/ them.
+When Mr. Blonde helps Mr. White rob a jewelry store it's a security failure for
+the store but a success for the crime gang.  When Mr. Orange (an undercover cop)
+shoots Mr. Blonde it's a security failure for the crime gang and a success for
+the police.  We want to know how to use
+
+  ( identity, past actions ) => (trust, future actions)
+
+If you can predict someone is a vandal or troll, don't let them change pages, or
+only let them post to Ye Flaming Pitte of Flamage.
+
+We can to reasonable satisfaction authenticate a token: only grant that
+identity to visitors who bear that token.  So this part is fine:
+  
+    person   (token)<- identity
+
+But we have no control over authentication token - identity correspondence.
+This part is broken:
+
+    person x (token)<- identity
+
+The only one who does have that control is the person behind that identity.
+They can reasonably guarantee
+  
+    person ->(token)<- identity
+
+If that person is going to be in your community, they have an interest in their
+identity: they want to be known as someone who isn't a punk, or doesn't troll,
+or does troll and better than anyone, or won't rat you out to the cops.  The
+actions of a person are moderated by their interest in maintaining their
+reputation:
+  
+    past actions -> reputation ->person
+
+So give up authorization in favor of auditing and recoverability, and authorize
+based on reputation -- on the past behavior and vouchsafes offered by the
+identity,
+  
+    reputation -> trust -> permissions ->actions
+
+They want to know that they have full control of their identity; among other
+things, privacy and an understanding that nobody can act without permission on
+their behalf. In fact, we can assure that only a token-holder can assume the
+corresponding identity:
+  
+    person ->(token)<->identity ->(trust) actions ->reputation ->person
+
+poop
+
+    reputation ->trust
+
+
+So we need to
+* Understand and encourage how their security interests aligns with ours,
+* Understand how it doesn't, and be robust in the face of that; and
+* Recover gracefully if it goes wrong.
+
+Instead of
+
+  authorization -> user -> token -> identity
+  
+we assign roles based on
+
+  authorization <- trust <- reputation <- identity <- token <- person
+

data/webgui/vendor/plugins/restful_authentication/notes/Tradeoffs.txt

@@ -0,0 +1,126 @@
+Guides to best practices:
+* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
+* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+* [[http://www.coresecuritypatterns.com/patterns.htm]]
+
+***************************************************************************
+h2. Session resetting
+
+Best practices recommend that you regenerate all session tokens (for us, the
+browser session ID and the remember_token cookie) on any privilege change (for
+us, logging in or logging out) -- see http://tinyurl.com/5vdvuq.  This release
+properly regenerates remember_token cookies, but does *not* by default
+reset_session.
+
+Calling reset_session can interact with Form Authentication tokens (a *much*
+more important security feature).  If a visitor logs in but has a form open in
+another tab, or uses the back button to pull one up from their history (perhaps
+the one that required them to log in), they will get the exceedingly unpleasant
+Request Forgery error.  Imagine spending twenty minutes crafting a devastating
+critique of this week's Battlestar Galactica episode, finding you need to log in
+before posting -- but then getting a Request Forgery when you re-attempt the
+post.  Frak!  Thus, it's disabled by default.
+
+On the other hand, this does moderately reduce your defense-in-depth against a
+"Cross-Site Request Forgery":http://en.wikipedia.org/wiki/CSRF attack.  To
+enable session_resetting, look for any
+   # reset session
+lines in the app/controllers/session_controller.rb and
+app/controllers/users_controller.rb and uncomment them.
+
+***************************************************************************
+h2. Site Key
+
+A Site key gives additional protection against a dictionary attack if your
+DB is ever compromised.  With no site key, we store
+  DB_password = hash(user_password, DB_user_salt)
+If your database were to be compromised you'd be vulnerable to a dictionary
+attack on all your stupid users' passwords.  With a site key, we store
+  DB_password = hash(user_password, DB_user_salt, Code_site_key)
+That means an attacker needs access to both your site's code *and* its
+database to mount an "offline dictionary attack.":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+
+It's probably of minor importance, but recommended by best practices: 'defense
+in depth'.  Needless to say, if you upload this to github or the youtubes or
+otherwise place it in public view you'll kinda defeat the point.  Your users'
+passwords are still secure, and the world won't end, but defense_in_depth -= 1.
+
+Please note: if you change this, all the passwords will be invalidated, so DO
+keep it someplace secure.  Use the random value given or type in the lyrics to
+your favorite Jay-Z song or something; any moderately long, unpredictable text.
+
+***************************************************************************
+h2. Password stretching
+
+If someone were to capture your user accounts database, they could farm it out
+for brute-force or dictionary-attack password cracking.  "Password Stretching"
+makes brute force (even with a compromised database and site key) attacks
+harder, and scales with Moore's law.  Basically, you apply the password
+encryption process several times, meaning that each brute-force attempt takes
+that much longer.  Hash your password ten times, and a brute-force attack takes
+ten times longer; hash 100,000 times and an attack takes 100,000 times longer.
+
+  bq. "To squeeze the most security out of a limited-entropy password or
+  passphrase, we can use two techniques [salting and stretching]... that are so
+  simple and obvious that they should be used in every password system.  There
+  is really no excuse not to use them. ... Choose stretching factor so computing
+  K from (salt, passwd) takes 200-1000 ms. Store r with the user's password, and
+  increase it as computers get faster." -- http://tinyurl.com/37lb73
+  Practical Security (Ferguson & Scheier) p350
+
+Now, adding even a 0.2s delay to page requests isn't justifiable for most online
+applications, and storing r is unnecessary (at least on your first design
+iteration).  But 
+  On a 1G Slicehost already under moderate load:
+  irb(main):005:0> puts Time.now; (10**6).times{ secure_digest(Time.now, rand) }; puts Time.now
+  Fri May 16 08:26:16 +0000 2008
+  Fri May 16 08:30:58 +0000 2008
+  => 280s/1M ~= 0.000_3 ms / digest
+A modest 10 (the default here) foldings makes brute forcing, even given the site
+key and database, 10 times harder at a 3ms penalty.  An app that otherwise
+serves 100 reqs/s is reduced to 78 signin reqs/s; an app that does 10reqs/s is
+reduced to 9.7 signin reqs/s
+
+* http://www.owasp.org/index.php/Hashing_Java
+* "An Illustrated Guide to Cryptographic Hashes":http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
+
+The default of 10 is a reasonable compromise, but the security-paranoid and
+resource-rich may consider increasing REST_AUTH_DIGEST_STRETCHES to match the
+one-second best-practices value, while those with existing userbases (whose
+passwords would otherwise no longer work) should leave the value at one.
+
+***************************************************************************
+h2. Token regeneration
+
+The session and the remember_token should both be expired and regenerated
+every time we cross the logged out / logged in barrier by either password
+or cookie.  ("To reduce the risk from session hijacking":http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+and brute force attacks, the HTTP server can seamlessly expire and
+regenerate tokens. This decreases the window of opportunity for a replay or
+brute force attack.)  It does mean we set the cookie more often.
+
+  http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+  http://palisade.plynt.com/issues/2004Jul/safe-auth-practices/
+
+
+***************************************************************************
+h2. Field validation
+
+We restrict login names to only contain the characters
+<nowiki>A-Za-z0-9.-_@</nowiki> This allows (most) email addresses and is safe
+for urls, database expressions (the at sign, technically reserved in a url, will
+survive in most browsers).  If you want to be more permissive:
+*  "URL-legal characters":http://www.blooberry.com/indexdot/html/topics/urlencoding.htm are <nowiki>-_.!~*'()</nowiki>
+*  "XML-legal characters":http://www.sklar.com/blog/archives/96-XML-vs.-Control-Characters.html are <nowiki>Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]</nowiki>
+*  "Email-address legal characters":http://tools.ietf.org/html/rfc2822#section-3.4.1 are <nowiki>0-9a-zA-Z!#\$%\&\'\*\+_/=\?^\-`\{|\}~\.</nowiki> but see "this discussion of what is sane"http://www.regular-expressions.info/email.html (as opposed to legal)
+
+We restrict email addresses to match only those actually seen in the wild,
+invalidating some that are technically allowed (characters such as % and ! that
+date back to UUCP days.  The line to allow all RFC-2822 emails is commented out,
+so feel free to enable it, or remove this validation.  See "this discussion of
+what is sane"http://www.regular-expressions.info/email.html as opposed to what
+is legal.  Also understand that this is just a cursory bogus-input check --
+there's no guarantee that this email matches an account or is even well-formed.
+
+If you change these validations you should change the RSpec tests as well.
+

data/webgui/vendor/plugins/restful_authentication/notes/Trustification.txt

@@ -0,0 +1,49 @@
+See also
+* "Trustlet Wiki":http://www.trustlet.org/wiki
+
+Potential Ingredients for a trust metric
+
+h2. Reputation
+
+* Web of trust
+* Reputation systems
+** Akismet, Viking, etc.
+
+* prove_as_human Completing a 
+* validate_email
+
+  logged_in
+  akismet, etc.
+  session duration
+
+h2. Accountability
+
+Does the person tied to this identity stand to lose or gain anything based on this action?
+
+
+h2. Past history
+
+* past history
+** we can revisit past trust decisions based on revised trust estimates
+* recency of errors (reduce trust on an application exception)
+
+h2. Commitment
+
+* are_you_sure -- ask for con
+* willingness to pay a "hate task" (compute big hash) a la Zed Shaw
+* send_me_one_cent a micropayment
+** shows commitment
+** secondary validation from payment system
+** offsets rist
+
+h2. Identity Binding
+
+* Stale sessions
+  bq. "If your application allows users to be logged in for long periods of time
+  ensure that controls are in place to revalidate a user’s authorization to a
+  resource. For example, if Bob has the role of “Top Secret” at 1:00, and at
+  2:00 while he is logged in his role is reduced to Secret he should not be able
+  to access “Top Secret” data any more." -- http://www.owasp.org/index.php/Guide_to_Authorization
+
+* how I authenticated: for instance, 'logged in by cookie' << 'logged in by password'
+

data/webgui/vendor/plugins/restful_authentication/rails/init.rb

@@ -0,0 +1,3 @@
+require File.join(File.dirname(__FILE__), "..", "lib", "authentication")
+require File.join(File.dirname(__FILE__), "..", "lib", "authentication", "by_password")
+require File.join(File.dirname(__FILE__), "..", "lib", "authentication", "by_cookie_token")