code100x / cms

Repo for https://app.100xdevs.com/
https://app.100xdevs.com/
1.06k stars 1.54k forks source link

bug: Unauthorized content and Non-Playable Videos Indexed in Search Results #1543

Open Caien1 opened 3 days ago

Caien1 commented 3 days ago

Describe the bug In the search functionality on the website [app.100xdevs.com], videos that should be restricted to specific cohorts (e.g., Cohort 3.0 in my case) are visible in the search results even for users without access. Additionally, courses I do have access to (e.g., ML and Android) are indexed in search results , but they are not playable.

To Reproduce Steps to reproduce the behavior:

  1. Log into app.100xdevs.com.
  2. Use the search bar to look for content related to Cohort 3.0 (in my case) or other restricted courses.
  3. Observe that videos from Cohort 3.0 and unplayable videos for accessible courses (ML, Android) appear in the results. Expected behavior Restricted Content: Only videos for which the user has access should appear in search results. Accessible Content: Search results should link to playable content for accessible courses without redirecting to unplayable pages.

Screenshots or GIFs image image

vinayak20130 commented 1 day ago

Yes, the bug does occur because of the following code:

const allVideos = await db.content.findMany({
  where: {
    type: 'video',
    hidden: false,
  },
  select: {
    id: true,
    parentId: true,
    title: true,
    parent: {
      select: {
        courses: true,
      },
    },
  },
});

This code is located in cms\src\app\api\search\route.ts, and it translates to the SQL query shown in the image below.

pgadmin

Proposed Solution

We need a query that would also check for userId while searching. If userId is already being saved somewhere, we could directly insert it into the file mentioned above. If not, changes will also have to be made in src\components\search\SearchBar.tsx (specifically at line 50) to also send the userId.

Changing the existing SQL query to include userId filtering doesn’t seem feasible, as it would require at least two joins, which could be computationally expensive. I would recommend a change in the schema, but this could lead to a snowball effect with other changes, such as:

APIs corresponding to these functionalities would need adjustments as well. Please let me know if this approach seems correct, as I am a fresher and would appreciate any feedback.