Re: [development] transferring session info across login event
i'm wondering if your statement: "the login event regenerates the session" is completely true. I don't believe that the php session cookie changes, and I don't see anywhere (or why) drupal would completely remove all $_SESSION info on login. I think what does happen is that Drupal's private session stuff as stored in the session table gets cleared out (primarily the user object that gets cached, i'm not sure what else), but you don't need to worry about that do you? Put all your pre-login stuff into $_SESSION and then it should still be there after login, I think. - Alan On Mon, Jul 14, 2008 at 1:37 PM, Joe Murray <joe.murray@jmaconsulting.biz> wrote:
I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome.
Cheers,
Joe Murray, PhD
President, JMA Consulting
@ The Centre for Social Innovation
215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7
416.466.1281, (416) 644-0116 (f)
joe.murray@jmaconsulting.biz
Skype: josephpmurray
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
I'd also like to know the proper technique for moving session data from anonymous to logged in user. This diff http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?r1=1.... shows how the session is now regenerated after a successful login and before the login hook is invoked. This change breaks the ability to login and keep the contents of your shopping cart in drupal e-commerce 5-3, for example. Maybe pre-login and post-login hooks are needed? --mark On Wed, Jul 23, 2008 at 7:08 AM, Alan Dixon <alan.g.dixon@gmail.com> wrote:
i'm wondering if your statement:
"the login event regenerates the session"
is completely true.
I don't believe that the php session cookie changes, and I don't see anywhere (or why) drupal would completely remove all $_SESSION info on login.
I think what does happen is that Drupal's private session stuff as stored in the session table gets cleared out (primarily the user object that gets cached, i'm not sure what else), but you don't need to worry about that do you?
Put all your pre-login stuff into $_SESSION and then it should still be there after login, I think.
- Alan
On Mon, Jul 14, 2008 at 1:37 PM, Joe Murray <joe.murray@jmaconsulting.biz> wrote:
I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome.
Cheers,
Joe Murray, PhD
President, JMA Consulting
@ The Centre for Social Innovation
215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7
416.466.1281, (416) 644-0116 (f)
joe.murray@jmaconsulting.biz
Skype: josephpmurray
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
Session ID regeneration is just that, a new session ID for the same session. Session variables are not overwritten. To test, I found my session ID, for an anonymous session, and did: UPDATE sessions SET session = 'debug|s:1:"a"' WHERE sid = '...'; After logging in, the session variables had not changed. Executing print_r($_SESSION); resulted in the expected Array ( [debug] => a ) -Neil On Fri, Jul 25, 2008 at 5:09 PM, mark burdett <mfburdett@gmail.com> wrote:
I'd also like to know the proper technique for moving session data from anonymous to logged in user.
This diff http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?r1=1.... shows how the session is now regenerated after a successful login and before the login hook is invoked. This change breaks the ability to login and keep the contents of your shopping cart in drupal e-commerce 5-3, for example. Maybe pre-login and post-login hooks are needed?
--mark
On Wed, Jul 23, 2008 at 7:08 AM, Alan Dixon <alan.g.dixon@gmail.com> wrote:
i'm wondering if your statement:
"the login event regenerates the session"
is completely true.
I don't believe that the php session cookie changes, and I don't see anywhere (or why) drupal would completely remove all $_SESSION info on login.
I think what does happen is that Drupal's private session stuff as stored in the session table gets cleared out (primarily the user object that gets cached, i'm not sure what else), but you don't need to worry about that do you?
Put all your pre-login stuff into $_SESSION and then it should still be there after login, I think.
- Alan
On Mon, Jul 14, 2008 at 1:37 PM, Joe Murray <joe.murray@jmaconsulting.biz> wrote:
I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome.
Cheers,
Joe Murray, PhD
President, JMA Consulting
@ The Centre for Social Innovation
215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7
416.466.1281, (416) 644-0116 (f)
joe.murray@jmaconsulting.biz
Skype: josephpmurray
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
To clarify, the issue I wrote about isn't related to $_SESSION, it's modules that store data in a separate table with session id as the key (as e-commerce does). It seems this may be a flawed data model unless there is some means for modules to respond to regenerated session ids. --mark On Fri, Jul 25, 2008 at 5:09 PM, mark burdett <mfburdett@gmail.com> wrote:
I'd also like to know the proper technique for moving session data from anonymous to logged in user.
This diff http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?r1=1.... shows how the session is now regenerated after a successful login and before the login hook is invoked. This change breaks the ability to login and keep the contents of your shopping cart in drupal e-commerce 5-3, for example. Maybe pre-login and post-login hooks are needed?
--mark
On Wed, Jul 23, 2008 at 7:08 AM, Alan Dixon <alan.g.dixon@gmail.com> wrote:
i'm wondering if your statement:
"the login event regenerates the session"
is completely true.
I don't believe that the php session cookie changes, and I don't see anywhere (or why) drupal would completely remove all $_SESSION info on login.
I think what does happen is that Drupal's private session stuff as stored in the session table gets cleared out (primarily the user object that gets cached, i'm not sure what else), but you don't need to worry about that do you?
Put all your pre-login stuff into $_SESSION and then it should still be there after login, I think.
- Alan
On Mon, Jul 14, 2008 at 1:37 PM, Joe Murray <joe.murray@jmaconsulting.biz> wrote:
I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome.
Cheers,
Joe Murray, PhD
President, JMA Consulting
@ The Centre for Social Innovation
215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7
416.466.1281, (416) 644-0116 (f)
joe.murray@jmaconsulting.biz
Skype: josephpmurray
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
Then the easiest thing to do is to use your own id set $_SESSION['ecommerce_cart_id']. -Neil On Fri, Jul 25, 2008 at 5:46 PM, mark burdett <mfburdett@gmail.com> wrote:
To clarify, the issue I wrote about isn't related to $_SESSION, it's modules that store data in a separate table with session id as the key (as e-commerce does). It seems this may be a flawed data model unless there is some means for modules to respond to regenerated session ids.
--mark
On Fri, Jul 25, 2008 at 5:09 PM, mark burdett <mfburdett@gmail.com> wrote:
I'd also like to know the proper technique for moving session data from anonymous to logged in user.
This diff http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?r1=1.... shows how the session is now regenerated after a successful login and before the login hook is invoked. This change breaks the ability to login and keep the contents of your shopping cart in drupal e-commerce 5-3, for example. Maybe pre-login and post-login hooks are needed?
--mark
On Wed, Jul 23, 2008 at 7:08 AM, Alan Dixon <alan.g.dixon@gmail.com> wrote:
i'm wondering if your statement:
"the login event regenerates the session"
is completely true.
I don't believe that the php session cookie changes, and I don't see anywhere (or why) drupal would completely remove all $_SESSION info on login.
I think what does happen is that Drupal's private session stuff as stored in the session table gets cleared out (primarily the user object that gets cached, i'm not sure what else), but you don't need to worry about that do you?
Put all your pre-login stuff into $_SESSION and then it should still be there after login, I think.
- Alan
On Mon, Jul 14, 2008 at 1:37 PM, Joe Murray <joe.murray@jmaconsulting.biz> wrote:
I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome.
Cheers,
Joe Murray, PhD
President, JMA Consulting
@ The Centre for Social Innovation
215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7
416.466.1281, (416) 644-0116 (f)
joe.murray@jmaconsulting.biz
Skype: josephpmurray
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
And for the love of god, keep the data you're saving small. Modules that store large amounts of data in the session, such as a fully loaded node, waste hundreds of megabytes of disk space from stale sessions. Seriously, burn the extra CPU cycles and keep the session size small. --Larry Garfield On Fri, 25 Jul 2008 17:59:12 -0700, "Neil Drumm" <drumm@delocalizedham.com> wrote:
Then the easiest thing to do is to use your own id set $_SESSION['ecommerce_cart_id'].
-Neil
On Fri, Jul 25, 2008 at 5:46 PM, mark burdett <mfburdett@gmail.com> wrote:
To clarify, the issue I wrote about isn't related to $_SESSION, it's modules that store data in a separate table with session id as the key (as e-commerce does). It seems this may be a flawed data model unless there is some means for modules to respond to regenerated session ids.
--mark
On Fri, Jul 25, 2008 at 5:09 PM, mark burdett <mfburdett@gmail.com> wrote:
I'd also like to know the proper technique for moving session data from anonymous to logged in user.
This diff
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?r1=1....
shows how the session is now regenerated after a successful login and before the login hook is invoked. This change breaks the ability to login and keep the contents of your shopping cart in drupal e-commerce 5-3, for example. Maybe pre-login and post-login hooks are needed?
--mark
On Wed, Jul 23, 2008 at 7:08 AM, Alan Dixon <alan.g.dixon@gmail.com> wrote:
i'm wondering if your statement:
"the login event regenerates the session"
is completely true.
I don't believe that the php session cookie changes, and I don't see anywhere (or why) drupal would completely remove all $_SESSION info on login.
I think what does happen is that Drupal's private session stuff as stored in the session table gets cleared out (primarily the user object that gets cached, i'm not sure what else), but you don't need to worry about that do you?
Put all your pre-login stuff into $_SESSION and then it should still be there after login, I think.
- Alan
On Mon, Jul 14, 2008 at 1:37 PM, Joe Murray <joe.murray@jmaconsulting.biz> wrote:
I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome.
Cheers,
Joe Murray, PhD
President, JMA Consulting
@ The Centre for Social Innovation
215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7
416.466.1281, (416) 644-0116 (f)
joe.murray@jmaconsulting.biz
Skype: josephpmurray
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
To clarify, the issue I wrote about isn't related to $_SESSION, it's modules that store data in a separate table with session id as the key (as e-commerce does). It seems this may be a flawed data model unless there is some means for modules to respond to regenerated session ids.
Did you already try: function mymodule_form_alter($form_id, &$form) { if ($form_id == 'user_login' || $form_id == 'user_login_block') { $form['submit'] = array('mymodule_pre_submit' => array()); $form['submit']['mymodule_post_submit'] = array(); } } function mymodule_pre_submit($form_id, $form_values, $return) { static $backup = array(); if ($return) { return $backup; } // Backup session data here $backup = ... // Invoke user login (hook_user) user_login_submit(...); } function mymodule_post_submit($form_id, $form_values) { // Reset session data $restored = mymodule_pre_submit(NULL, NULL, TRUE); } ? Just an idea. But yes, dealing with hook_user() forms is quite a mess...
That would be the last resort but I think I can fix it by following Neil's suggestion: saving the cart/session id in $_SESSION so it's not lost. --mark On Fri, Jul 25, 2008 at 6:04 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
To clarify, the issue I wrote about isn't related to $_SESSION, it's modules that store data in a separate table with session id as the key (as e-commerce does). It seems this may be a flawed data model unless there is some means for modules to respond to regenerated session ids.
Did you already try:
function mymodule_form_alter($form_id, &$form) { if ($form_id == 'user_login' || $form_id == 'user_login_block') { $form['submit'] = array('mymodule_pre_submit' => array()); $form['submit']['mymodule_post_submit'] = array(); } }
function mymodule_pre_submit($form_id, $form_values, $return) { static $backup = array(); if ($return) { return $backup; } // Backup session data here $backup = ... // Invoke user login (hook_user) user_login_submit(...); }
function mymodule_post_submit($form_id, $form_values) { // Reset session data $restored = mymodule_pre_submit(NULL, NULL, TRUE); }
? Just an idea.
But yes, dealing with hook_user() forms is quite a mess...
participants (5)
-
Alan Dixon -
Daniel F. Kudwien -
Larry Garfield -
mark burdett -
Neil Drumm