Timeline for Store information from hook_form_alter to be used in later hook_user_update?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2013 at 21:18 | comment | added | Software Prophets | @znerol Ah, okay I'll buy that one! I was stuck on the happy path. Thanks for the tutelage. | |
| Nov 25, 2013 at 18:20 | comment | added | znerol |
@edl: If validation fails due to input errors, hook_user_update will not be called and therefore the unset would never happen. When working with the $_SESSION, always assume that the value will end up in the database.
|
|
| Nov 25, 2013 at 17:09 | comment | added | Software Prophets | @jcorall, Someone is going to need to tell my Drupal installation that your solution doesn't work. Without the unset, yes, it's in the DB. With the unset, the password does not show in the session table. Still, drupal_static is a better solution, as it more easily avoids bugs due to typos in the unset, so update away! | |
| Nov 25, 2013 at 16:07 | history | edited | Joe Corall | CC BY-SA 3.0 |
deleted 653 characters in body; deleted 1 characters in body
|
| Nov 25, 2013 at 16:05 | comment | added | Joe Corall | @edl, znerol is correct. Using the $_SESSION variable will record the plaintext password in the database. I will update the answer later this evening. | |
| Nov 25, 2013 at 13:20 | comment | added | Software Prophets | @znerol Upon further research, it appears Drupal uses session_set_save_handler, which, "Is invoked when PHP shuts down or explicitly when session_write_close() is called." Drupal does make calls here and there, but it does look like so long as an unset it called, the answer given would not store the plain text password. Thanks to everyone for the help! | |
| Nov 25, 2013 at 12:50 | comment | added | Software Prophets | @znerol I appreciate you pointing out drupal_static. That's exactly what I was looking for when I said, "Drupal specific solution" above. I'm concerned though that you might be being unduly concerned? Noting that jcorall indicates that I should, "unset the plain text variable at the end of your hook_user_update() logic" that would likely ensure that it doesn't end up in the database, right? I don't know the lifecycle of $_SESSION as it relates to storage in the database, but it probably stores at the end of the request which would be well after the unset, so jcorall's answer is fine, right? | |
| Nov 24, 2013 at 13:19 | comment | added | znerol |
@jcorall: It would be much saver to use a normal global variable or the drupal_static pattern. Please update your answer and advice against using $_SESSION.
|
|
| Nov 24, 2013 at 13:14 | comment | added | znerol |
@edl and anyone else, please do not follow the advice given in this answer. The content of $_SESSION superglobal gets stored into the database. Ultimately the clear-text passwords of your users will end up in the sessions-table in your Drupal database.
|
|
| Nov 23, 2013 at 13:53 | comment | added | Joe Corall | Because the validate function only gets called right after the user submits the form. If you put your validate/processing code in the form_alter() implementation, the form_alter() can get cluttered up pretty quick. IMO, better to keep form processing (validate) and form displaying (form_alter) code separate. | |
| Nov 23, 2013 at 12:47 | comment | added | Software Prophets | I kind of figured this would be the solution and I agree that most everything seems to be available in the $edit argument, except for the plain text password. One question: I'm curious why you suggest adding a validate versus just adding the session assignment in hook_form_user_profile_form_alter? | |
| Nov 23, 2013 at 12:45 | vote | accept | Software Prophets | ||
| Nov 23, 2013 at 1:16 | review | First posts | |||
| Nov 23, 2013 at 2:27 | |||||
| Nov 23, 2013 at 0:57 | history | answered | Joe Corall | CC BY-SA 3.0 |