SMF Development > Fixed or Bogus Bugs

session ID and session name incompatibility issue

(1/1)

mkmeister:
Bug description: SMF functionality breaks when sharing domain cookies with another web application that sets session ids using the same session name as SMF and when that session id doesn't pass SMF's validation (e.g. longer than 32 characters).
Versions affected: ALL
File: Sources/Load.php (in all versions)
Settings: Use database drive sessions
Operations affected: Anything that relies on reading and writing session data


I've done some searches across the boards here, and I am unable to find an existing thread for this. I believe this to be classified a bug. Someone else may have a different opinion. It doesn't affect the operation of SMF when a domain's cookies only apply to SMF, but if it shares domain cookies with another web application that can set it's own session id and the session id format used isn't restricted to 16-32 alpha-numeric characters, it will break anything that relies on SESSION data.

In the custom session handlers (located in Sources/Load.php), SMF will try to read an existing session ID. That's fine, except in the cases that another web application that uses the same domain cookies sets a session id that doesn't fit in the norm when using the same session name as SMF. This is very common, as some applications will append a server identifying string to, for example, a 32byte md5 string that can be useful in some load balancing setups (among other things). If the session id string is longer than 32 characters and isn't strictly alpha-numeric, it won't be able to read or write session data.

This problem could be solved in 1 of 2 ways.

The sessions table column of "session_id" could be increased to a more flexible char(50). This increase is minimal, especially for a table with temporary data, and allows more flexibility in how session id strings may be formatted by other web applications. The validation would also have to be changed to allow for up to 50 characters, and possibly allow other non-alphanumeric characters (such as a hyphen or underscore).

Alternatively, and the route I'd recommend, is that an option could simply be added to change the session name. That would solve the same problem without doing database or validation changes.

EDIT: Changed the name of the topic to one that is more appropriate.

mkmeister:
Nobody has any comments on this? Or am I just crazy?

emanuele:
Is this a bug?
Could this be partially related to this?

emanuele:
commit 07162b27cb044a2e1cff30903c992f778fa25e01
Author: emanuele
Date:   Sun May 6 2012

    ! Session ids supported up to 64 chars and rawlogic's fix for sessions expanded to all the checks in Session.php


commit 708ce3d69ae1a2845872521c50501533ef0ef62b
Author: emanuele
Date:   Tue May 1 2012

    ! Session ids longer than 32 chars would have problems in storing their value into the database (thanks postgre) and few other install/upgrade fixes

These two changes should alleviate the issue...hopefully.

Navigation

[0] Message Index