[903] | 1 | John,
|
---|
| 2 |
|
---|
| 3 | I have been an extremely satisfied ADODB user for several years now.
|
---|
| 4 |
|
---|
| 5 | To give you something back for all your hard work, I've spent the last 3
|
---|
| 6 | days rewriting the adodb-session.php code.
|
---|
| 7 |
|
---|
| 8 | ----------
|
---|
| 9 | What's New
|
---|
| 10 | ----------
|
---|
| 11 |
|
---|
| 12 | Here's a list of the new code's benefits:
|
---|
| 13 |
|
---|
| 14 | * Combines the functionality of the three files:
|
---|
| 15 |
|
---|
| 16 | adodb-session.php
|
---|
| 17 | adodb-session-clob.php
|
---|
| 18 | adodb-cryptsession.php
|
---|
| 19 |
|
---|
| 20 | each with very similar functionality, into a single file adodb-session.php.
|
---|
| 21 | This will ease maintenance and support issues.
|
---|
| 22 |
|
---|
| 23 | * Supports multiple encryption and compression schemes.
|
---|
| 24 | Currently, we support:
|
---|
| 25 |
|
---|
| 26 | MD5Crypt (crypt.inc.php)
|
---|
| 27 | MCrypt
|
---|
| 28 | Secure (Horde's emulation of MCrypt, if MCrypt module is not available.)
|
---|
| 29 | GZip
|
---|
| 30 | BZip2
|
---|
| 31 |
|
---|
| 32 | These can be stacked, so if you want to compress and then encrypt your
|
---|
| 33 | session data, it's easy.
|
---|
| 34 | Also, the built-in MCrypt functions will be *much* faster, and more secure,
|
---|
| 35 | than the MD5Crypt code.
|
---|
| 36 |
|
---|
| 37 | * adodb-session.php contains a single class ADODB_Session that encapsulates
|
---|
| 38 | all functionality.
|
---|
| 39 | This eliminates the use of global vars and defines (though they are
|
---|
| 40 | supported for backwards compatibility).
|
---|
| 41 |
|
---|
| 42 | * All user defined parameters are now static functions in the ADODB_Session
|
---|
| 43 | class.
|
---|
| 44 |
|
---|
| 45 | New parameters include:
|
---|
| 46 |
|
---|
| 47 | * encryptionKey(): Define the encryption key used to encrypt the session.
|
---|
| 48 | Originally, it was a hard coded string.
|
---|
| 49 |
|
---|
| 50 | * persist(): Define if the database will be opened in persistent mode.
|
---|
| 51 | Originally, the user had to call adodb_sess_open().
|
---|
| 52 |
|
---|
| 53 | * dataFieldName(): Define the field name used to store the session data, as
|
---|
| 54 | 'DATA' appears to be a reserved word in the following cases:
|
---|
| 55 | ANSI SQL
|
---|
| 56 | IBM DB2
|
---|
| 57 | MS SQL Server
|
---|
| 58 | Postgres
|
---|
| 59 | SAP
|
---|
| 60 |
|
---|
| 61 | * filter(): Used to support multiple, simulataneous encryption/compression
|
---|
| 62 | schemes.
|
---|
| 63 |
|
---|
| 64 | * Debug support is improved thru _rsdump() function, which is called after
|
---|
| 65 | every database call.
|
---|
| 66 |
|
---|
| 67 | ------------
|
---|
| 68 | What's Fixed
|
---|
| 69 | ------------
|
---|
| 70 |
|
---|
| 71 | The new code includes several bug fixes and enhancements:
|
---|
| 72 |
|
---|
| 73 | * sesskey is compared in BINARY mode for MySQL, to avoid problems with
|
---|
| 74 | session keys that differ only by case.
|
---|
| 75 | Of course, the user should define the sesskey field as BINARY, to
|
---|
| 76 | correctly fix this problem, otherwise performance will suffer.
|
---|
| 77 |
|
---|
| 78 | * In ADODB_Session::gc(), if $expire_notify is true, the multiple DELETES in
|
---|
| 79 | the original code have been optimized to a single DELETE.
|
---|
| 80 |
|
---|
| 81 | * In ADODB_Session::destroy(), since "SELECT expireref, sesskey FROM $table
|
---|
| 82 | WHERE sesskey = $qkey" will only return a single value, we don't loop on the
|
---|
| 83 | result, we simply process the row, if any.
|
---|
| 84 |
|
---|
| 85 | * We close $rs after every use.
|
---|
| 86 |
|
---|
| 87 | ---------------
|
---|
| 88 | What's the Same
|
---|
| 89 | ---------------
|
---|
| 90 |
|
---|
| 91 | I know backwards compatibility is *very* important to you. Therefore, the
|
---|
| 92 | new code is 100% backwards compatible.
|
---|
| 93 |
|
---|
| 94 | If you like my code, but don't "trust" it's backwards compatible, maybe we
|
---|
| 95 | offer it as beta code, in a new directory for a release or two?
|
---|
| 96 |
|
---|
| 97 | ------------
|
---|
| 98 | What's To Do
|
---|
| 99 | ------------
|
---|
| 100 |
|
---|
| 101 | I've vascillated over whether to use a single function to get/set
|
---|
| 102 | parameters:
|
---|
| 103 |
|
---|
| 104 | $user = ADODB_Session::user(); // get
|
---|
| 105 | ADODB_Session::user($user); // set
|
---|
| 106 |
|
---|
| 107 | or to use separate functions (which is the PEAR/Java way):
|
---|
| 108 |
|
---|
| 109 | $user = ADODB_Session::getUser();
|
---|
| 110 | ADODB_Session::setUser($user);
|
---|
| 111 |
|
---|
| 112 | I've chosen the former as it's makes for a simpler API, and reduces the
|
---|
| 113 | amount of code, but I'd be happy to change it to the latter.
|
---|
| 114 |
|
---|
| 115 | Also, do you think the class should be a singleton class, versus a static
|
---|
| 116 | class?
|
---|
| 117 |
|
---|
| 118 | Let me know if you find this code useful, and will be including it in the
|
---|
| 119 | next release of ADODB.
|
---|
| 120 |
|
---|
| 121 | If so, I will modify the current documentation to detail the new
|
---|
| 122 | functionality. To that end, what file(s) contain the documentation? Please
|
---|
| 123 | send them to me if they are not publically available.
|
---|
| 124 |
|
---|
| 125 | Also, if there is *anything* in the code that you like to see changed, let
|
---|
| 126 | me know.
|
---|
| 127 |
|
---|
| 128 | Thanks,
|
---|
| 129 |
|
---|
| 130 | Ross
|
---|
| 131 |
|
---|