should I alter the sessions table?
I have a special need, in the Drupal for Facebook modules, to honor a session key that comes from Facebook, instead of the key Drupal normally uses. So far the way I've approached this is to have Drupal use the passed-in session_key, so the sid column of the sessions table is that value. My problem is the the length of these session keys is sometimes longer than the 64 character limit of the sid column. According to Facebook these keys could be 128 characters or even longer. (http://forum.developers.facebook.com/viewtopic.php?id=21931) My first thought is to alter Drupal's sessions table. That is, in my module's .install file I would alter sessions so that the sid column is varchar(256) instead of varchar(64). Is there a performance drawback to this? Is it bad form to alter the table this way? My other options include finding some way to compress the session_key down to 64 chars. Or, create a table that maps longer session_keys to Drupal's sids. Is there any reason to go with one of these options as opposed to altering the table? Thanks in advance, -Dave
David Cohen wrote:
My first thought is to alter Drupal's sessions table
Personally, what I would do (and have done) is to go ahead and alter the table. Then I would turn around and post a patch to core explaining the use case. My guess is that this would be accepted (with some arguing of course) to be put into D7. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.11.33/2031 - Release Date: 3/30/2009 5:56 PM
On Tue, Mar 31, 2009 at 11:47 AM, David Cohen <drupal@dave-cohen.com> wrote:
Is there a performance drawback to this?
Probably not a perceptible one - table scans will walk the length of a varchar, so you'll be walking some 256-length entries when there are Facebook sessions active... not really a big deal imo.
Is it bad form to alter the table this way?
That might be the sticking point. I can see some problems arising quickly from letting modules alter core tables: -FB Connect sets sid to varchar(256) -Foo.module, installed later, sets sid to varchar(128) Now FB Connect doesn't work. Quick alternate ideas that come to mind: -Setting a PHP session instead -Making a mapping table of FB sid -> drupal sid -Doing what you're considering, but instead storing the FB sids as md5 hashes in the sessions table to keep the varchar(64) constraint -Some combination of these -D
2009/3/31 David Cohen <drupal@dave-cohen.com>:
I have a special need, in the Drupal for Facebook modules, to honor a session key that comes from Facebook, instead of the key Drupal normally uses. So far the way I've approached this is to have Drupal use the passed-in session_key, so the sid column of the sessions table is that value. My problem is the the length of these session keys is sometimes longer than the 64 character limit of the sid column. According to Facebook these keys could be 128 characters or even longer. (http://forum.developers.facebook.com/viewtopic.php?id=21931)
My first thought is to alter Drupal's sessions table. That is, in my module's .install file I would alter sessions so that the sid column is varchar(256) instead of varchar(64). Is there a performance drawback to this? Is it bad form to alter the table this way?
Surely there will be a performance hit, due to longer indexes.
My other options include finding some way to compress the session_key down to 64 chars. Or, create a table that maps longer session_keys to Drupal's sids. Is there any reason to go with one of these options as opposed to altering the table?
Can't you just save you key in a session variable (e.g. $_SESSION['fb_key']) ? Henrique
Thanks in advance,
-Dave
On Tue, Mar 31, 2009 at 12:18 PM, Henrique Recidive <recidive@gmail.com>wrote:
Surely there will be a performance hit, due to longer indexes.
Barely perceptible, I'd wager. The indexes will only grow (in comparison to current) when there are entries of length >64 (varchar isn't padded). But the "session" field is a longtext, so it isn't exactly a high-performing table as it is. (just looking at a D5 install, YMMV for D6+). But it's probably beside the point because: Can't you just save you key in a session variable (e.g. $_SESSION['fb_key'])
?
^this! :) -D
Here's what I've learned since my original post... Changing sid from varchar(64) to varchar(255) or shorter would have no effect on a regular drupal install, because the length of the strings can still be expressed in 1 byte. With my modules installed some session keys would be greater than 64 chars, which could add some overhead to the index of the table. (I may be underestimating the impact of the change, if mysql somehow uses the max length in building a more efficient index.) On Tue, 31 Mar 2009 12:39 -0700, "Domenic Santangelo" <domenic@workhabit.com> wrote:
On Tue, Mar 31, 2009 at 12:18 PM, Henrique Recidive <recidive@gmail.com>wrote:
Can't you just save you key in a session variable (e.g. $_SESSION['fb_key'])
?
Definitely not. We're talking about the session key, the very thing that makes it possible for $_SESSION to persist from one request to the next. (When serving a Facebook Canvas Page, cookies are not honored and the session_key _must_ be used instead.) Facebook's session keys include extra information, like start time and expiry, which do not contribute to the uniqueness. (Or so I believe.) So for the time being I'm trying to solve this problem by truncating the very long session keys, as that seems easier than altering the table.
Definitely not. We're talking about the session key, the very thing that makes it possible for $_SESSION to persist from one request to the next. (When serving a Facebook Canvas Page, cookies are not honored and the session_key _must_ be used instead.)
This scares me a bit. Will you make users aware of this core modification? Or is your module supposed to be used by advanced users only? At least, it sounds a bit like the latter. settings.php: $conf = array( 'session_inc' => './sites/all/modules/facebook/session.inc', ); There, join your own facebook_sessions table and/or do any magic or own session handling as you like. sun
Yes I do what you suggest, though the code is not identical. Users of these modules must modify their settings.php to include the module's code. There's no core modification for this. -Dave On Tuesday 31 March 2009 13:49:51 Daniel F. Kudwien wrote:
Definitely not. We're talking about the session key, the very thing that makes it possible for $_SESSION to persist from one request to the next. (When serving a Facebook Canvas Page, cookies are not honored and the session_key _must_ be used instead.)
This scares me a bit. Will you make users aware of this core modification? Or is your module supposed to be used by advanced users only? At least, it sounds a bit like the latter.
settings.php:
$conf = array( 'session_inc' => './sites/all/modules/facebook/session.inc', );
There, join your own facebook_sessions table and/or do any magic or own session handling as you like.
sun
participants (6)
-
Daniel F. Kudwien -
Dave Cohen -
David Cohen
-
Domenic Santangelo -
Henrique Recidive -
Nancy Wichmann