• 0

Should I create a unique MySQL user per logged in person?


Question

Yo Neowin!

I want to know what do you suggest in terms of security, and speed, whether is recommended or not to create an individual user for each person that logs in to my site.

I mean. I usually verify a username on a table, and assign unique tables to each of my users with a General MySQL user account with limited privileges. But since I've been reading a little bit more about MySQL (I only know the basics), I've seen that to improve security I could assign certain limits on MySQL users and only allow access to certain tables.

So, what can you suggest me in terms of MySQL users?

Thanks :p

14 answers to this question

Recommended Posts

  • 0
  On 04/01/2013 at 14:01, SuperKid said:

What do you mean unique mysql user per logged in user, what type of site is this?

I mean, to create a MySQL user. The default user on a MySQL server is root. I would like to know if it would improve security having a separate user like "John" which would only access Joh_products and John_clients table and will have limited privileges like SELECT, DROP, UPDATE, INSERT commands.

This site, is on development right now, so everything can be modified. It's a receipt management website, which each of the users will have their own clients stats, number of purchases, receipts, etc.

  • 0
  On 04/01/2013 at 14:06, Jose_49 said:

I mean, to create a MySQL user. The default user on a MySQL server is root. I would like to know if it would improve security having a separate user like "John" which would only access Joh_products and John_clients table and will have limited privileges like SELECT, DROP, UPDATE, INSERT commands.

This site, is on development right now, so everything can be modified. It's a receipt management website, which each of the users will have their own clients stats, number of purchases, receipts, etc.

I truly would not recommend that at all.

  • 0

NEVER use the root account AT ALL once you've configured the MySQL server, make another account and grant it root-like permissions and ONLY use the root account as a last resort if something breaks to restore everything.

Yes use different accounts for different sites, one account for all clients on one site should be fine i.e. one account for this receipt tracking site, another account for a control panel site, etc.

  • 0

You should only really need one master user for the mysql database itself. Then use web based forms (in PHP for example) to allow the people to add/delete/update their data. They don't need to have direct access to the database tables to do this. I don't really see the point of having totally distinct tables for each user either. Seems like a lot of duplication and you'll end up with a massive amount of tables.

  • 0

Thanks to all of the above. Now I have a clear mind.

  On 04/01/2013 at 14:15, n_K said:

NEVER use the root account AT ALL once you've configured the MySQL server, make another account and grant it root-like permissions and ONLY use the root account as a last resort if something breaks to restore everything.

Yes use different accounts for different sites, one account for all clients on one site should be fine i.e. one account for this receipt tracking site, another account for a control panel site, etc.

I shall take this recommendation then :)

  On 04/01/2013 at 14:28, technikal said:

I don't really see the point of having totally distinct tables for each user either. Seems like a lot of duplication and you'll end up with a massive amount of tables.

:/ There was no other way my logic could function.

I Googled a bit and found that there wasn't any problem having multiple tables. The thing is that it allows flexibility. I didn't see a good way on putting the client info, the receipt #, the quantity, price of the product purchased (because it has a variable price), the current product id, the tax, and whether it was paid, delivered or not. So I could fetch it in a productive way later on....

Anyways, I'm open to suggestions :D

  • 0
  On 04/01/2013 at 15:48, Jose_49 said:

I Googled a bit and found that there wasn't any problem having multiple tables. The thing is that it allows flexibility. I didn't see a good way on putting the client info, the receipt #, the quantity, price of the product purchased (because it has a variable price), the current product id, the tax, and whether it was paid, delivered or not. So I could fetch it in a productive way later on....

Multiple tables are fine, in fact you should be using multiple tables, but there's a much better and organized way of using them. You should be using different tables for storing types of data. If I have Users, Customers, and Receipts; I would create a separate table for each one of them. Then I would create two additional tables used for associations, one for Users->Receipts, and one for Customers->Receipts. These associative tables would only store the unique id's for the rows in the other tables.

Not sure if I explained clear enough or not, also not sure if it's quite the same idea as your system. Either way its best to have different table's for different types of data, since there's no sense in storing the same data multiple times.

  • 0

Certainly use multiple tables, but not for each user. Say you have 10 users and each user has a separate table, if you want to see all the data from all the users you have to search through 10 tables, vs. just the main table for the type of data you want.

So instead of userA_orders, userB_orders, etc. you just have a single orders table, and store what user created the order in the record you insert into the table.

  • 0

if i've read this right. you should create a function user. one user that can insert, update, or delete records, but not modify the database structure. use that user for any transaction, and the root as a last resort.

  • 0
  On 05/01/2013 at 06:34, mollick2 said:

Multiple tables are fine, in fact you should be using multiple tables, but there's a much better and organized way of using them. You should be using different tables for storing types of data. If I have Users, Customers, and Receipts; I would create a separate table for each one of them. Then I would create two additional tables used for associations, one for Users->Receipts, and one for Customers->Receipts. These associative tables would only store the unique id's for the rows in the other tables.

Not sure if I explained clear enough or not, also not sure if it's quite the same idea as your system. Either way its best to have different table's for different types of data, since there's no sense in storing the same data multiple times.

  On 05/01/2013 at 06:44, The_Decryptor said:

Certainly use multiple tables, but not for each user. Say you have 10 users and each user has a separate table, if you want to see all the data from all the users you have to search through 10 tables, vs. just the main table for the type of data you want.

So instead of userA_orders, userB_orders, etc. you just have a single orders table, and store what user created the order in the record you insert into the table.

Now I get it! Yup. Indeed. I know my logic was failing somewhere.

I just need to create a separate column with the current logged in user, and bang it with a WHERE clause to identify the user (*poker face*)

Aaaargh.

Going to work on it right now

Thank you people :D

This topic is now closed to further replies.
  • Posts

    • PC manufacturers used to trick BIOS copyright strings to get full editions of trial software by Usama Jawad You may have noticed that when you purchase a new PC, it comes with certain software pre-installed. Sometimes, when you open this software, it activates, and you receive the full version of it without paying any additional cost. This is because that PC's manufacturer is a licensee of that software and the fact that a customer gets the full version of a trial software for free serves as a perk for potential buyers. However, many PC manufacturers tried to trick this process in its infancy. During the days of Windows 95, when the Plug and Play specification was still in development, the OS' engineering team was trying to figure out ways through which it could identify PCs that existed prior to the inception of this specification. To that end, one of the methods they tried was searching for copyright strings and firmware dates in the BIOS. Through the course of this investigation, they discovered a rather oddly named copyright string "Not Copyright Fabrikam Computer" in a PC that was actually manufactured by Contoso. In this case, both Fabrikam and Contoso are fictional names that are used to describe this scenario without revealing the actual identity of the OEMs involved. Microsoft engineer Raymond Chen explains in a blog post that these odd copyright strings were actually appearing because Contoso PCs contained a trial version of a software and the company wanted the full version to be activated for customers even though it was not an official licensee. In order to bypass the costly licensing process, what the firm did was that it added the following text to its copyright string: "Copyright Contoso Not Copyright Fabrikam Computer". The trial version of said software would search for the string "Copyright Fabrikam Computer" and end up finding it within the substring of the convoluted copyright string mentioned above, accidentally activating the software's full version. While more robust ways were adopted later to avoid this problem, it's certainly interesting to see that OEMs would go to this length in order to distribute software that they are not officially allowed to. Well, as they say, the past stays in the past.
    • Uhm... a couple of issues with this. First, you're engaging in revisionist history. People weren't dragged from Win 7 to Win 10. You've kind of glossed over a whole cycle there: Win 8/8.1. People stayed on 7 because they hated 8/8.1 and held on until 10 showed up. THEN they actually started to switch voluntarily. Second, it's not about the OS, it's about the workflow. OS fans consistently miss this. People have work to do and they've invested a lot of time, effort and even money building their workflows. It's expensive to change so, that change has to offer real benefits that compensate for the cost of updating workflow and sorry, Win 11 just doesn't. That's the same reason they won't just jump to an entirely new OS - which has an even bigger workflow cost - until there's just no other option. Not only is there the core workflow cost, but the cost of finding new parallel software for the new OS, transferring and possible converting files and dealing with incompatibilities and then redeveloping workflows. It's just not as simple as "switch". And now there IS another option, stay on Win 10 for another year and pray for Win 12 (much as Win 7 users did with Win 8 - which happened when Win 10 came out).
    • Microsoft has some PC VR games that could be played with it.
  • Recent Achievements

    • Week One Done
      DrRonSr earned a badge
      Week One Done
    • Week One Done
      Sharon dixon earned a badge
      Week One Done
    • Dedicated
      Parallax Abstraction earned a badge
      Dedicated
    • First Post
      956400 earned a badge
      First Post
    • Week One Done
      davidfegan earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      616
    2. 2
      ATLien_0
      227
    3. 3
      +FloatingFatMan
      170
    4. 4
      Michael Scrip
      166
    5. 5
      Som
      148
  • Tell a friend

    Love Neowin? Tell a friend!