By fago on

i'm currently editing the user.module and the profile.module so that they fit my special needs. so i discovered the serialized data field in the users table. drupal stores there everything, which is submitted by the browser!!

is this the intended behaviour?
so everyone could come and store hundreds MB of nonesense in my database!!!?

further, which information does drupal store there?
since the profile.module uses it own table, is this field still needed?

Comments

Steven’s picture

Steven commented

Various small things about a user are stored there: the choice of theme, the locale, the time zone, etc.

You can prevent fields from being stored by unsetting them in $edit before passing them to user_save. This is required for data that is already stored in external tables.

--
If you have a problem, please search before posting a question.

fago’s picture

fago
Primary language German
Location Vienna
commented

i just commented out 

          else {
            $data[$key] = $value;
          }

in the user_save function.
so drupal stores no additional fields in the database.
seems to work for me.

but why is this data stored serialized in this field, when there are extra fields for it in the users table??

and isn't it unsecure letting everyone store stuff in this field? so anyone can fill your database with a lot of trash, which drupal loads into memory..

nautis’s picture

nautis commented

i'd like to bump this back up since there was no response. i'm also curious why drupal is using serialized data. this seems like a design flaw.

- matthew | nautis.com

robertDouglass’s picture

robertDouglass commented

I'm not going to address the original question here but rather the idea that storing serialized data is a design flaw. When we know in advance that some data is going to be stored, it ends up in a column of a table all its own, and in most cases in normalized form. In this way the Drupal DB schema is pretty good. However, Drupal extends a generous offer to anyone programming it; add a field to the $user object any time before calling user_save and it will be persisted. For example, if you were to make a blog entry and use the PHP Code input filter and do the following:

global $user;

print_r($user);

$user->important_data = "hi world";
user_save($user, array('important_data' => $user->important_data));

this would get serialized and saved to the database. It turns out to be a nifty way to extend the functionality offered without having to hack core modules. Of course, if you are going to save gobs of crucial data this way you're going to run into problems, so you'd be better off extending the user table.

Serialized data is used in other ways in Drupal as well, most notably in the cache table where the menus are cached. Revisions are also saved as serialized data. So in some cases, serializing data makes sense and doesn't immediately indicate a design flaw.

- Robert Douglass

-----
www.robshouse.net
www.webs4.com

robertDouglass’s picture

robertDouglass commented

I expect if you look at the serialized data carefully you'll find that it stored the data which isn't already found in another column of the users table. If this is not the case, and fields like uid, name and pass are getting serialized and stored, this is a bug, in which case you should note which version of Drupal you are using and file a bug report.

- Robert Douglass

-----
www.robshouse.net
www.webs4.com

fago’s picture

fago
Primary language German
Location Vienna
commented

sry, i've missed your answer 'til now.

it looks like i've explained it quite bad. i have just posted a bugreport for this, which i've should done earlier.

hopefully, i've better explained it there.

sami_k’s picture

sami_k commented

Replace
Line 186 with:
if ((substr($key, 0, 4) !== 'auth') && (!in_array($key, $user_fields)) && ($value !== null) && (substr($key, 0, 4) !== 'priv')) {

Then use priv_ for the form field.

--
Read the handbook, search the forums, then ask!
http://drupal.etopian.net (Consulting, Development, and Hosting)