pubcookie module returns "page not found" after authenticating

Um. Why are you using a development snapshot? Use an actual release (currently 5.x-1.0 for Drupal 5).

Also, many security updates have been released since Drupal 5.3. Upgrade to 5.9.

If you want to know exactly what's happening with the pubcookie module, edit the module and change the line

define('PUBCOOKIE_DEBUG_MODE', 0);

to

define('PUBCOOKIE_DEBUG_MODE', 1);

Before you do that, you might want to check the watchdog. Pubcookie records a lot of information there.

To "back out" the pubcookie module installation, simply disable it.

This installation started Nov 2007 and got put on the shelf due to other priorities. The -dev version was the only thing available for download.

What are the diffs between 5.x-1.x-dev and 5.x-1.0? I unpacked both tar archives and ran a diff -r on them and didn't see anything.

I already tried setting PUBCOOKIE_DEBUG_MODE to 1 but didn't get any additional logging info. The only error I get is:
page not found 07/24/2008 - 14:00 PubCookie.reply

This results in the Drupal "page not found" screen.

The issue is that, for some reason, the URL that the pubcookie module is supposed to go to isn't getting used and I can't see how to fix that.

Any ideas?

Thanks,
Carl

What are the pubcookie watchdog entries that are written? Have you followed the instructions in the README, including the section on how it works? Are clean URLs enabled? What does the Apache log contain (this will confirm which path is being requested)?

Checking Google for PubCookie.reply leads me to this page. Sounds like your pubcookie is configured to come back to /PubCookie.reply.

I was having this same problem with the latest stable release of pubcookie (3.3.3 as of this writing).

I believe this has to do with a change in the default method that pubcookie uses to pass messages between the apache module and the login server.

As of pubcookie 3.3.2, this method now uses HTTP POST requests and javascript by default, whereas prior to this, the "classic" method used HTTP GET and a meta-refresh.

What ended up working for me was falling back to using the classic method:

PubcookieLoginMethod GET

Note that if you use the GET method, you'll need to configure the PubcookieDomain directive to match exactly what you put in the "Domain" field of the drupal pubcookie module config. You should also unset your PubcookiePostURL directive, if you have it set.

Also, I found that the phpsession create by drupal after successful pubcookie login doesn't expire when the pubcookie auth does, which means that people will still be logged in to drupal even after their pubcookie auth expires. I used the Autologout module to work around that.

Another issue that crept up was that people were still logged in to drupal after shutting down their browser. Changing the drupal session lifetime in sites/default/settings.php to 0 fixed that:

ini_set('session.cookie_lifetime', 0);

Hope this helps

Fwiw, I was able to get the pubcookie drupal module to work using PubcookieLoginMethod POST. It turns out that the process of enabling clean urls mucks with the newer version of pubcookie auth. To work around this, make sure that your apache rewrite rules look like this:

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/PubCookie.reply$
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Also, if anybody can figure out how to make drupal+pubcookie do the following, I'd owe them a beer or three:

1. User loads root drupal page, i.e. http://www.foo.com
2. If user is already authenticated via pubcookie, user is logged in and given all their normal privileges
3. If user is NOT already authenticated via pubcookie, the normal drupal page appears, i.e. that served to
unauthenticated users.
4. If a user comes back to the root drupal page and reloads after authenticating via another pubcookie page,
there are served their normal page as in #2.
5. User can alternately click on the "log in" link in the drupal menu to be logged in.

I'd like to know if it's possible to engineer some way to have the user returned to the page from which they initiated the login. I use a login link at the top of my page that redirects them to their university login. After authentication is complete, can we pass their last location through the whole process somehow or would I have to hijack together some kind of assumption about who the user is in order to send them back to the same place in my site's hierarchy?

I'm looking in to this, but I thought I'd post my question in the meantime.

I'm having the same issue as mentioned by the users above - pubcookie returning a "page not found."

Background:
I have pubcookie running somewhat successfully on a "drupal 6.11 production" server. The somewhat means that after entering my username and pw, I get returned to a blank/white page, but refreshing the page brings me to a pubcookie logged in page and everything proceeds fine.

However, on a development server that is the same setup - drupal 6.11, I cleared the cache via settings/performance as well as the browser cache and now pubcookie is sending me to a page not found. It keeps thinking "pc" is a page in drupal and I can't figure out how to make it not think it's a page. The only thing different on the development server is that I wrote a simple module to display a cck field in a block when/where that cck field exists.

I've tried all the suggestions above as we are running the latest pubcookie (3.3.3) and none worked. I also disabled the addon, removed the pubcookie folder and signin folder (containing the .htaccess file), cleared the cache and reinstalled pubcookie and it is still thinking "pc" is a page. I've also tried renaming the folder to pubcookie2 and no luck. All of this being done with closing out the browser completely.

The location of the .htaccess file for pubcookieAppId setup is:
drupal_site/sites/all/signin/.htaccess

Watchdog before the caching was stating entries like:
uid = 3
type = pubcookie
message = uid of authenticated user is %uid
variables = a:1{a bunch of %uid stuff}

uid = 0
type = pubcookie
message = session ID is %sessid
variables = a:1{a bunch of session stuff}

uid = 0
type = pubcookie
message = Received login request from $user
variables = a:1{a bunch of user stuff}

This all appears healthy to me, but now post clearing the cache it looks unhealthy as shown below.

Now watchdog is:
uid = 0
type = access denied
message = node/15
variables = N;

uid = 0
type = page not found
message = /sites/all/signin/pc
variables = N;

One other thing to note is that turning on the debugging in the pubcookie.module doesn't print any statements.

Any thoughts or suggestions as to why clearing the cache would have caused this issue and how to fix it?

Take a look at your apache access log to determine if there's any silent redirection taking place.

Clearing the cache would clear the menu cache (see "Why it works" in the pubcookie module README).

The verbose logging not happening is weird. Are you using APC to cache PHP? If so, apache would need to be restarted after you turn on verbose logging in pubcookie.module.

Thanks for the reply. I didn't think to look at the database to see what was getting stored in the menu tables. Once I did, I compared the test server to the production server and noticed the weird stuff that happened with the caching.

It's working now on the test server.

Thanks again.