1. 10 Oct, 2016 1 commit
  2. 07 Jul, 2016 1 commit
  3. 06 Jul, 2016 1 commit
  4. 05 Jul, 2016 1 commit
  5. 04 Dec, 2014 1 commit
  6. 30 Jul, 2014 1 commit
  7. 14 Jul, 2014 1 commit
  8. 16 Jun, 2014 1 commit
    • Alex Pyrgiotis's avatar
      astakos: Allow sending customizable emails · 3e159e3c
      Alex Pyrgiotis authored
      Add a `send_plain` function in `im/user_utils.py`. With the `send_plain`
      function, the admin can send a fully customizable mail to an
      AstakosUser. The admin can either choose to use the provided body
      template (`plain_email.txt`) and subject, or write his/her own.
      3e159e3c
  9. 23 May, 2014 1 commit
  10. 13 May, 2014 1 commit
    • Kostas Papadimitriou's avatar
      astakos: Projects views enhancements · 1226d973
      Kostas Papadimitriou authored
      - Include total quota help text for each resource.
      - Two column layout for per user/total quota.
      - Fixed owner formatters in template filters.
      - Proper display of unset project application resources.
      - Hide base projects by default. Include base project toggling action in
        projects list view.
      - Set proper project name field validators for base project in
        project modifcation form.
      - Improve visual highlighting of quota diffs
      - Improve membership status messages
      - Improved project filtering in project list/join views
      - List all public/active projects in `join project` view.
      - Handle unowned projects in projects modification form
      - Display all project resources in project application summary view.
      - Permit zero values in project application/modification form.
      - Avoid modifcation of immutable base project fields in project modification
        view.
      - Display project/application creation date to project admins.
      - Remove user base project when a user gets removed.
      - Convert ProjectForbidden exception to 403 http responses.
      - Additional user access checks handling in project/app detail view.
      - Let both applicant and project admins to dismiss a denied project
        application.
      - Forbid project owner to act upon an admin project modification.
      - Prevent POST requests in project modification detail view.
      - Handle pending app quota per applicant
        When applying for a modification, the existing pending modifications,
        which will be replaced, may have been initiated by another user. We need
        thus to handle the astakos.pending_app resource per applicant.
      - Introduce `related`, `active` mode in projects list api call
        Related mode returns all projects user owns or is has a related
        membership to. Active mode returns available public/active projects.
      1226d973
  11. 14 Apr, 2014 1 commit
    • Vangelis Koukis's avatar
      Switch license to GPLv3 · 02071b96
      Vangelis Koukis authored
      According to the decision of the GRNET Board of Directors,
      switch license to GPLv3.
      
      This commit will be propagated to the release
      and master branches based on git flow, and the next
      release will be licensed as GPLv3.
      02071b96
  12. 28 Feb, 2014 1 commit
  13. 13 Feb, 2014 3 commits
  14. 20 Dec, 2013 1 commit
  15. 19 Dec, 2013 1 commit
  16. 07 Oct, 2013 1 commit
    • Kostas Papadimitriou's avatar
      astakos: Shibboleth EPPN migration functionality · 3a6c7968
      Kostas Papadimitriou authored
      Prior to this commit astakos used the mod_shib2 EPPN header value as the
      unique identifier for associating shibboleth idp users to astakos user entries.
      
      This commit alters this behaviour and from now on astakos resloves unique
      identifier from the REMOTE_USER header. REMOTE_USER is a header mod_shib2 sets
      containing a value of the available shibboleth IdP metadata. The metadata
      key (persistent-id or eppn in most common scenarios) used can be configured
      from within shibboleth2.xml config file.
      
      <ApplicationDefaults id="default" .... .... REMOTE_USER="persistent-id"...>
      
      An additional setting ``ASTAKOS_SHIBBOLETH_MIGRATE_EPPN`` is added in order
      to facilitate migration of existing EPPN entries to persistent-id/targeted-id
      (or whichever metadata the REMOTE_USER maps to). When set to ``True``, after
      each shibboleth login astakos will try to migrate the existing EPPN entry
      by following the below mentioned steps:
      
      * If no REMOTE_USER header exists or is empty, redirect to an error view.
        Otherwise continue to the next step.
      * Resolve EPPN header and check if an account is currently associated with this
        EPPN.
      * If user exists, retrieve user's shibboleth entry (AstakosUserAuthProvider
        instance) and replace stored identifier (EPPN) with the identifier contained
        in REMOTE_USER header.
      * Continue to login or signup process using REMOTE_USER value as the unique
        user identifier that associates astakos user to the shibboleth account.
      3a6c7968
  17. 10 Sep, 2013 1 commit
    • Constantinos Venetsanopoulos's avatar
      astakos: fix verification message · 9cc1bdb4
      Constantinos Venetsanopoulos authored
      The new registration process of Astakos allows to verify the new
      user's email before actually activating the user:
      
      1. User signs up providing an email
      2. A verification email is sent to the user (with verification link)
      3. A corresponding message is shown on the Astakos web page
      4. If the user follows the link he/she gets 'verified'
      5. The new user is now verified=True, active=False
      6. If moderation=False or the admin activates the user manually then
         the user gets verified=True, active=True and is granted access to
         the system
      
      This commit changes the message on (3) to reflect the above changes.
      9cc1bdb4
  18. 07 Aug, 2013 3 commits
  19. 16 Jul, 2013 1 commit
  20. 11 Jul, 2013 1 commit
  21. 05 Jul, 2013 1 commit
  22. 17 Jun, 2013 2 commits
  23. 28 May, 2013 1 commit
  24. 21 May, 2013 1 commit
  25. 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`
        command.
      - 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 ->
              account_pending_moderation_notification.txt
      - Updated im tests
      7319c9be
  26. 08 May, 2013 1 commit
  27. 24 Apr, 2013 1 commit
  28. 08 Apr, 2013 1 commit
  29. 27 Mar, 2013 1 commit
  30. 15 Mar, 2013 2 commits
    • Kostas Papadimitriou's avatar
      Auth providers improvements · ef4cb65f
      Kostas Papadimitriou authored
      - Improved logging
      - Messages changes
      - Fixes in local module login/add policies handling
      ef4cb65f
    • 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
        settings::
      
        # 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
        AUTH_PROVIDER_SHIBBOLETH_ADD_POLICY = False
      
      - 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
      518bbefd
  31. 27 Feb, 2013 2 commits
  32. 14 Feb, 2013 2 commits