Invitation Design
  • Token Generation - at least 64-bit
  • Which server


For setting up the email (find a better place for this):

State Diagram for Invitations

  • Show life-cycle of Invitations
  • When do they expire?
  • When are they acknowledged?
  • Does Activity play into this?
  • When do we request that a user supply their own password? Otherwise, do we have much confidence that the account is theirs if someone else picks up the invitation? I think we need to have the user select a password as soon as they accept the invitation and we'll want to also provide a means of linking in Facebook and/or Google accounts. Resetting a password needs to be another options

Activity Diagrams for Invitations


Class Diagram for Invitations



There are a few options for authentication:

  • Let the Invitation serve as the authentication; weakness is anyone with the email can login as that user, no verification that the user is who the token says it is, encrypted or not. This is certainly suitable for the anonymous armchair and perhaps the logged in armchair seekers as well.
  • Create a separate token that serves as authentication. A few ways to do this:
    • On landing page, email a separate link with short-lived token that establishes the cookie through an encrypted session.
    • On landing page, send SMS token that establishes the cookie through an encrypted session.


  1. When Seeker first accepts an invitation, there will be a jsessionid for the session, and an invitation token, but no authentication cookie. This means we need to authenticate the user who is establishing the session is the person we think they are.
  2. Although there are two options under consideration, the first one to implement is to send a confirmation email to the address of record with a short-lived token. This email is sent to the same address as the invitation and expires within minutes.
  3. When confirming the link in this email, a cookie is set with the Authentication Token. This token will live a configurable period of time, probably about 30 days and will avoid having to confirm again for that period of time.
  4. Once the Authentication Token is set as a cookie, this will allow the user's session to be confirmed as active. Requests to view the invitation will see the state as active.
  5. If the user changes pages or otherwise leaves the site, upon returning, the authentication token along with the invitation token will be sufficient to reconnect the Seeker with their outing. No need to re-authenticate.
  6. Declining an invitation is assumed to mean no interest in establishing credentials and no attempt to Authenticate is presented for that invitation. We accept at face value a declination of an invitation.

Business Rules

  • Authentication Token cannot expire in the middle of an Outing.
  • Authentication Token can be re-used for more than one Outing; the invitation token distinguishes outings.
  • Authentication Token is persisted in case of server restarts.
  • Authentication Token will show up under a different cookie key should more than one account share the same device.
  • Should an invitation be accidentally declined, it is possible to re-open the invitation.



  • The Member class will hold the list of Badges.
  • The Badge Service will build its list from the instances read from the MemberStore; no need for a BadgeStore.
  • Invitations hold a Member Reference which can then be used to index into the Member Service to obtain the Badges.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License