Storing Users

March 30, 2015, 03:07:10 pm

I've been thinking a lot lately about how users are stored. I feel like there should be an "auth" table which is just a user id, a login (email or username or both), and a password field. That should be the entire table. Everything else should be stored in "user_attributes" or something similar. Each row has user_id, field_id, attribute. The field id would correspond to the custom profile fields table.

I like this because in the future, I can see the software getting more secure and modular. Where the authorization doesn't necessarily happen with Elkarte or access to the auth table is highly controlled. You could use a separate service. You could use a separate database user. You can use a stored procedure and not allow queries to directly access it. You can store that table in a different database. There are tons of ways to make it even more secure. Not necessarily a big deal right now.

So, more importantly and less off-the-wall, is that it gives the admin the ability to control every attribute with ease. First off, I can control the default ones much easier. Then, for things like the memberlist, I can add to that easier. Now, instead of having a default list of things for the memberlist, it will be completely configurable. You go to the memberlist editor and select which attributes you want to show on the list, then you drag and drop where the columns are. That would be it. Every attribute is searchable and sortable.

This would mean that there is an additional query per page. That shouldn't matter much if you cache them. You could do a cache lookup for two things at once in memcached. The keys could be "user_auth_$id"and "user_attr_$id". Users might have attributes that don't need to be downloaded for every page. Maybe the custom_fields should have a list of what fields should be downloaded by page.

Re: Storing Users

Reply #1 – March 31, 2015, 06:00:48 am

Yep, I guess that's somehow what I wanted to describe in the issue #1452.

I think (TBH I don't remember my original idea, one year it's a long time), I was more thinking to a less "drastic" approach, in the sense that I was thinking to drop just what is not really always useful, though even that approach of yours has its advantages. nods