delta/gitlab/gitlab-ce.git/app/controllers/dashboard, branch api-shared-groups

Fix an information disclosure when requesting access to a group containing private projects

2016-06-24T10:01:48+00:00

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: Rémy Coutable

Ensure Todos counters doesn't count Todos for projects pending delete

2016-06-17T19:17:43+00:00

Cache todo counters (pending/done)

2016-06-17T17:04:36+00:00

- As todos are created/updated inside the TodoService
we repopulate the cache just there for both pending/done todos
- Todos as mark as done from the TodosController we update cache
there too
- All the added methods are kept in the User class for cohesion

Merge branch 'meinac/gitlab-ce-change_deprecated_render_usage'

2016-05-18T17:48:23+00:00

Signed-off-by: Dmitriy Zaporozhets

Merge branch '17249-starred' into 'master'

2016-05-11T12:49:29+00:00


Restrict starred projects to viewable ones

`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.

Closes #17249.

See merge request !4108

Restrict starred projects to viewable ones

2016-05-10T17:13:52+00:00

`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.

Add to label :id to response

2016-05-03T16:58:43+00:00

Add missing Dashboard::LabelsController

2016-03-23T11:02:15+00:00

Use respond_to instead of a conditional to paginate milestones

2016-03-23T11:02:15+00:00

Fix an issue causing the Dashboard/Milestones page to be blank

2016-03-23T11:02:15+00:00