Filter bug when session.cookie_secure is set
druido - May 6, 2009 - 14:13
| Project: | Bibliography Module |
| Version: | 6.x-1.4 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
In a web site using Drupal 6.11 with Secure Pages activated (with default settings), Biblio's filter functionality is broken. To reproduce:
1) create a bibliography;
2) as an anonymous user, go to the bibliography page;
3) be sure that the link is prefixed by http, not https, i.e., something like http://my.site.com/biblio
4) click on "Filter" and filter by any criteria.
The result will show all bibliography items instead of the filtered ones.
If you repeat the steps above under https (e.g., https://my.site.com/biblio), items are filtered correctly.
#1
Hmm, no doubt has something to do with the use of "Session variables" for filtering. Session variables have been creating other problems as well and there was some discussion of getting rid of them completely, so this may be the straw that breaks that camels back.
#2
You might want to check out this thread... http://drupal.org/node/65890#comment-1009009, it looks like a small modification to your php.ini file might be all that's necessary.
#3
I've read the thread, but I'm not sure I got what should be changed. The bug is due to the fact that I have set session.cookie_secure in my php configuration (and I have unchecked “Switch back to http pages when there are no matches” in Secure Pages settings, but that shouldn't matter for the problem we are discussing). In fact, if I unset session.cookie_secure, all is fine, but, of course, there are good reasons to set it. So, the question is: is Biblio module incompatible with this setting or is there a way to make it work? I have tried to set $cookie_domain in my settings.php to different values, but with no luck.
PS: I have verified that the bug manifests itself even without Secure Pages: it just depends on session.cookie_secure, so I am changing the issue title.
#4
I have the same problem with drupal 5 - and I got quite a nasty fix which may also work for you.
The problem lies within drupal's session handling itself. I have configured my own dummy user in drupal via the web interface and using it's user id if an unauthenticated user tries to create a filter by directly hacking biblio rather than the drupal framework itself. An unauthenticated user is switch to "my dummy user" in the back ground if he is about to create a filter.
In detail:
In sess_read() in session.inc a dummy unauthenticated users is created by calling drupal_anonymous_user() from bootstrap.inc. That seems to be done because of some performance? reason. This standard anonymous users does have an "empty session" variable associated with it. Therefore I have added the following code:
function biblio_form_filter() {
#markus' hack (drupal does not create session if user->id==0 in session.inc, therefore I am reimplementing here drupal_anonymous_user() from bootstrap.inc with a already set up dummy user )
global $user;
if(!$user->uid){
$user = new stdClass();
$user->uid = XXX;
$user->hostname = $_SERVER['REMOTE_ADDR'];
$user->roles = array();
$user->roles[DRUPAL_ANONYMOUS_RID] = 'anonymous user';
$user->session = array();
session_start();
$user->cache = 0;
}
### hack ends
----you may want to additionally redirect the login page to a page which "logs users XXX out again"
.....
Because this is actually a drupal-core problem (if you like) I have created an issue here: http://drupal.org/node/514438
If you have a more elegant solution - please let me know :)