Understanding Web App Permissions with MySQL

0 投票
最新提问 用户: (120 分)

Assume I have a schema defined with the 4 following entities:

Users 
  -> Timeline (fk: userId)
    -> Entries (fk: timelineId)
      -> Tags (fk: entryId), where fk means foreign key.

Now, let's say I want to check in the web application if a user has permission to delete a particular tag. Right now I use Basic Authentication, check if the user's email // password exist in the database, and if so, grab the userId.

Because of the userId only existing on the Timeline entity, I feel like I'd need to do the following:

DELETE t.* FROM `tags` AS t
  INNER JOIN `entries` AS e ON t.entryId = e.id
  INNER JOIN `timelines` AS tl ON e.timelineId = tl.id
WHERE
  tl.userId = ? AND
  t.id = ?

This approach works, but I feel like it would be inefficient. Instead, I could add a userId FK to every single table such as the tags, but that also seems like a maintenance nightmare.

I can't think of any other approaches other than implementing some other type of permission system, such as using an ACL. Any suggestions?

2 个回答

0 投票
最新回答 用户: (140 分)

Check out foreign keys here. You can simply add relationships through MySQL to the other tables, and cascade delete when the parents get removed.

发表于 用户: (120 分)
This is unrelated to what I'm asking. I'm trying to verify the user has permissions to delete a particular entry. Also, I'm not deleting any parent entries, so I'm not sure how your response helps.
0 投票
最新回答 用户: (4.1k 分)

I think you can choose from a few options:

  • leave it as is until it actually becomes a problem and fix it then (it probably won't be a problem, there's a lot of optimization in MySQL)
  • add foreign keys to tables as you proposed and take the overhead on changes (your models / data access layer should hide the problem from higher layers anyway)
  • implement some kind of custom caching
    • you can either create something like a cache table, probably in a nosql database like Redis, which would be very fast (once a permission is retrieved, it can live in the cache for a while, but be aware of consequences, for example permission changes will not be immediate)
    • you can use memcache
    • you can do custom in-memory caching in your app (be careful with using the session for this, session-related vulnerabilities might allow an attacker more access than you intended)

Basically and in general it's a compute / storage tradeoff I think. You either compute permissions every time or store them pre-computed somewhere, which means you need to re-compute them sometimes (but probably not all the time).

The right solution depends on your exact scenario. My experience is that in most cases it's not worth to fix something that is not broken yet (unless of course you know it will not work that way in the scenario you want to use it in).

欢迎来到 Security Q&A ,有什么不懂的可以尽管在这里提问,你将会收到社区其他成员的回答。
...