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 | |
---|