BigW Consortium Gitlab

  1. 12 Aug, 2016 1 commit
    • Recover usage of Todos counter cache · f8b53ba2
      Paco Guzman authored
      We’re being kept up to date the counter data but we’re not using it.
      The only thing which is not real if is the number of projects that the 
      user read changes the number of todos can be stale for some time.
      
      The counters will be sync just after the user receives a new todo or mark any as done
  2. 12 Jul, 2016 1 commit
  3. 24 Jun, 2016 1 commit
    • Fix an information disclosure when requesting access to a group containing private projects · aec3475d
      Rémy Coutable authored
      The issue was with the `User#groups` and `User#projects` associations
      which goes through the `User#group_members` and `User#project_members`.
      
      Initially I chose to use a secure approach by storing the requester's
      user ID in `Member#created_by_id` instead of `Member#user_id` because I
      was aware that there was a security risk since I didn't know the
      codebase well enough.
      
      Then during the review, we decided to change that and directly store the
      requester's user ID into `Member#user_id` (for the sake of simplifying
      the code I believe), meaning that every `group_members` / `project_members`
      association would include the requesters by default...
      
      My bad for not checking that all the `group_members` / `project_members`
      associations and the ones that go through them (e.g. `Group#users` and
      `Project#users`) were made safe with the `where(requested_at: nil)` /
      `where(members: { requested_at: nil })` scopes.
      
      Now they are all secure.
      Signed-off-by: 's avatarRémy Coutable <remy@rymai.me>
  4. 17 Jun, 2016 2 commits
  5. 03 Jun, 2016 2 commits
  6. 10 May, 2016 1 commit
    • Restrict starred projects to viewable ones · 97424ea5
      Sean McGivern authored
      `User#starred_projects` doesn't perform any visibility checks. This has
      a couple of problems:
      
      1. It assumes a user can always view all of their starred projects in
         perpetuity (project not changed to private, access revoked, etc.).
      2. It assumes that we'll only ever allow a user to star a project they
         can view. This is currently the case, but bugs happen.
      
      Add `User#viewable_starred_projects` to filter the starred projects by
      those the user either has explicit access to, or are public or
      internal. Then use that in all places where we list the user's starred
      projects.
  7. 03 May, 2016 1 commit
  8. 01 Apr, 2016 1 commit
  9. 30 Mar, 2016 1 commit
  10. 23 Mar, 2016 3 commits
  11. 19 Mar, 2016 1 commit
  12. 18 Mar, 2016 1 commit
  13. 17 Mar, 2016 3 commits
  14. 16 Mar, 2016 1 commit
  15. 10 Mar, 2016 1 commit
  16. 04 Mar, 2016 1 commit
  17. 03 Mar, 2016 3 commits
  18. 02 Mar, 2016 1 commit
  19. 23 Feb, 2016 1 commit
  20. 21 Feb, 2016 1 commit
  21. 20 Feb, 2016 9 commits
  22. 09 Feb, 2016 2 commits
  23. 05 Feb, 2016 1 commit