1. 15 Oct, 2013 1 commit
  2. 21 May, 2013 1 commit
  3. 20 May, 2013 1 commit
  4. 16 May, 2013 1 commit
  5. 15 May, 2013 1 commit
    • Kostas Papadimitriou's avatar
      astakos: User activation flow improvements · 7319c9be
      Kostas Papadimitriou authored
      Major refactoring on user email verification/activation process
      Activation logic moved from dispersed code in functions/view modules to
      ActivationBackend methods. All user activation handling code in astakos views
      and command line utilities was updated to use activation backend instances.
      User moderation takes place right after user has verified the email address used
      during the signup process. This solves issues caused when users signed up using
      an existing but not yet verified email, causing invalidation of previously
      moderated accounts.
      A bunch of new fields added in AstakosUser model. Those fields added to clear up
      a bit the identification of user status at a given time and additionaly keep
      track of when specific user actions took place as a reference for
      administrators. The following section contains detailed description of each
      introduced field.
      Introduced AstakosUser fields
      Fields get properly set across sigup/activation/moderation processes.
      * verification_code
        Unique identifier used instead of user auth token in user email
        verification url. This is initially set when user signup and gets updated
        each time a new verification mail is sent (requested either by admin or user)
      * verified_at
        The date user email got verified.
      * moderated
        Whether or not the used passed through moderation process.
      * moderated_at
        The date user got moderated.
      * moderated_data
        A snapshot of user instance by the time of moderation (in json format).
      * accepted_policy
        A string to identify if user was automatically moderated/accepted.
      * accepted_email
        The email used during user activation.
      * deactivated_reason
        Reason user got deactivated, provided by the administrator.
      * deactivated_at
        Date user got deactivated.
      * activated_at
        Date user got activated.
      * is_rejected
        Whether or not account was rejected.
      South data migration included.
      Handles user entries as follows
      Users with no activation_sent date
      - Generate and fill verification_code field.
      - Once user will visit the activation url an additional moderation step
        will be required to activate the user.
      Users with verified email which are not active
      - Set moderated to True
      - Set is_active to False
      - Set moderated_at to user.auth_token_created
      - Set accepted_email to user.email
      - Set accepted_policy to 'migration'
      - Set deactivated_reason to "migration"
      - Set deactivated_at to user.updated
      Users with verified email which are active
      - Set moderated to True
      - Set moderated_at to user.auth_token_created
      - Set accepted_policy to 'migration'
      - Set accepted_email to user.email
      - Set verified_at to user.moderated_at
      Users with no verified email and activation_sent set
      - Set moderated to True
      - Set moderated_at to user.updated
      - Set verification_code to user.auth_token (to avoid invalidating old
        activation urls)
      Updated management commands
      - New options --pending-moderation, --pending-verification added in `user-list`
      - New fields verified/moderated included in `user-list` command.
      - New moderation options `--accept`/`--reject` added in `user-modify` command.
        `--reject` can optionally be combined with `--reject-reason`.
      Other changes
      - Cleaned up explicit smtp error handling when sending email notifications.
      - Prevent already signed in users from using an account activation url
      - Allow user to logout even when latest terms where not accepted
      - Renamed templates
          * helpdesk_notification.txt -> account_activated_notification.txt
          * account_creation_notification.txt ->
      - Updated im tests
  6. 15 Mar, 2013 2 commits
    • Kostas Papadimitriou's avatar
      Astakos logging improvements · 7dca7ef3
      Kostas Papadimitriou authored
      use the common user_log display method accross logging calls
    • Kostas Papadimitriou's avatar
      Authentication providers improvements · 518bbefd
      Kostas Papadimitriou authored
      Major authentication provider refactoring to support
      - Modular and easily configurable messages with common context
      - Fine grained provider policies to support appling specific policies to
        users and/or groups
      Key points:
      - Use auth_providers.AuthProvider instances where auth provider logic is
        needed. Instances get properly initialized with the available context
        (with no user/signup view, with user/login view, with user and
        identifier/profile view).
      - All authentication provider messages are now accessed using the
        get_*_msg AuthProvider attributes.
      - Provider policies logic is handled from  get_*_policy attributes.
      - All provider messages may be overridden globally or per provider level from
        # global change
        ASTAKOS_AUTH_PROVIDER_NOT_ACTIVE = 'Provider not active'
        # change only applies to shibboleth provider
        ASTAKOS_AUTH_PROVIDER_SHIBBOLETH_NOT_ACTIVE = 'Shibboleth is not  active'
      - Provider policies may be overridden in settings::
        # ALL users wont be able to add shibboleth login method from their
        # profile
      - New provider policies profile model added. Profiles can be assigned to
        a group or/and a specific user.
      - All tests updated to match the auth providers changes.
      - New management commands included
        * user-auth-policy-{add, list, remove, set, show}
          Manage authentication provider policy profiles.
        * user-group-{add, list}
          User group management commands
      - Updated user-list to optionally display auth provider information
  7. 04 Jan, 2013 1 commit
  8. 17 Dec, 2012 1 commit
  9. 14 Dec, 2012 1 commit
  10. 03 Dec, 2012 2 commits
  11. 30 Nov, 2012 1 commit
  12. 19 Nov, 2012 1 commit
  13. 16 Nov, 2012 1 commit
  14. 13 Nov, 2012 2 commits
  15. 09 Nov, 2012 1 commit
  16. 05 Nov, 2012 2 commits
  17. 10 Sep, 2012 1 commit
  18. 03 Sep, 2012 1 commit
  19. 29 Aug, 2012 1 commit
  20. 28 Aug, 2012 1 commit
  21. 19 Jul, 2012 1 commit
  22. 30 May, 2012 1 commit
    • Sofia Papagiannaki's avatar
      Register the date a user activation email sent and reset it when the user... · 4a3321c6
      Sofia Papagiannaki authored
      Register the date a user activation email sent and reset it when the user becomes active (for future use)
      This field can have the following values:
      * epoch:						signifies the user has been created before adding the specific field (so we have no actually information whether an activation email has been sent or not)  
      * NULL:							signifies the user is active or no activation email has been sent
      * other date (except epoch):	 the date the activation email sent
      Passing the -n option in list users snf command shows only the new users (created after adding the field) who have not received an activation.
      Refs: #2471
  23. 07 May, 2012 1 commit
  24. 21 Apr, 2012 1 commit
  25. 11 Apr, 2012 1 commit
  26. 09 Apr, 2012 1 commit
  27. 07 Apr, 2012 1 commit
  28. 03 Apr, 2012 1 commit
  29. 14 Mar, 2012 1 commit
  30. 13 Mar, 2012 1 commit
  31. 09 Mar, 2012 1 commit
  32. 07 Mar, 2012 1 commit
    • Sofia Papagiannaki's avatar
      Automatically activate users whose email matches specific email patterns... · 8316698a
      Sofia Papagiannaki authored
      Automatically activate users whose email matches specific email patterns defined in settings (ASTAKOS_RE_USER_EMAIL_PATTERNS) &  minor other fixes:
      * introduce email_verified AstakosUser field and if False during signup send email verification
      * show recaptcha fields in signup form in case of invited user
      * do not allow multiple invitations with the same receiver
      * enable user level modification by ``snf-manage modifyuser``
      Refs: #2166
  33. 05 Mar, 2012 1 commit
  34. 04 Mar, 2012 1 commit
  35. 01 Mar, 2012 2 commits