MongoDB按用户ID获取指定用户websites数组方案咨询

Hey there! I totally get the struggle of switching from SQL to NoSQL—it’s a paradigm shift that takes a minute to wrap your head around. Let’s break down your question clearly, focusing on security first (since that’s non-negotiable here) and then walk through the implementation details.

First off, passing a userId directly from the frontend via a click event is a huge security risk. Any user could tamper with that value in their browser’s dev tools and request another user’s website data. We need a reliable, server-side way to confirm who’s making the request—and sessions are the most straightforward solution for this.

Why Sessions Are Safer #

• Session data lives on your server, not the frontend. The user only gets a session ID (stored in a cookie), which they can’t modify to impersonate someone else.
• On every authenticated request, your server uses that session ID to look up the actual user, ensuring they can only access their own data.

Step-by-Step Implementation (Mongoose + Express) #

Assuming you’re using Express with Mongoose (the most common stack for this), here’s how to make this work:

1. Set Up User Login & Session Storage #

When a user logs in, validate their credentials, then store their _id in the session:

// Login route example (using bcrypt for password hashing)
app.post('/login', async (req, res) => {
  const { username, password } = req.body;

  // Find the user by username
  const user = await User.findOne({ username });
  if (!user) {
    return res.status(401).send('Invalid username or password');
  }

  // Verify the password (always hash passwords! Never store plain text)
  const isPasswordValid = await bcrypt.compare(password, user.password);
  if (!isPasswordValid) {
    return res.status(401).send('Invalid username or password');
  }

  // Store the user's ID in the session
  req.session.userId = user._id;
  res.send('Login successful!');
});

2. Create an Authentication Middleware #

Make a middleware to check that the user is logged in before allowing access to sensitive routes:

const requireAuth = (req, res, next) => {
  // Check if the session has a valid user ID
  if (!req.session.userId) {
    return res.status(401).send('Please log in to access this resource');
  }
  next(); // Proceed to the route handler if authenticated
};

3. Fetch the User’s Websites Safely #

Use the middleware in your route, then query the User collection using the session’s userId—and only return the websites field to keep things efficient:

app.get('/my-websites', requireAuth, async (req, res) => {
  // Find the user by ID, and only select the websites field (ignore other data like password)
  const user = await User.findById(req.session.userId).select('websites');

  if (!user) {
    return res.status(404).send('User not found');
  }

  // Send back the websites array
  res.json(user.websites);
});

When Is Passing a User ID Acceptable? #

Only if you’re building an admin dashboard where a privileged user needs to view other users’ data. Even then, you must add an extra layer of validation to confirm the current user is an admin before allowing the request. For example:

app.get('/admin/user/:userId/websites', requireAuth, async (req, res) => {
  // First, check if the current user is an admin
  const currentUser = await User.findById(req.session.userId);
  if (!currentUser || !currentUser.isAdmin) {
    return res.status(403).send('Access denied');
  }

  // Now fetch the target user's websites
  const targetUser = await User.findById(req.params.userId).select('websites');
  res.json(targetUser?.websites || []);
});

Quick NoSQL Mindset Tip #

Coming from SQL, you might be tempted to create a separate Website collection and join it with User—but in MongoDB, embedding the websites array directly in the User document is perfect here. It’s faster to query (no joins needed) and aligns with how NoSQL prioritizes denormalization for read performance.

内容的提问来源于stack exchange，提问作者Alex Ironside