First time users get the login screen, second time works as expected.

[Keitht]

 I have postnuke.762, coppermine 1.45 and pncpg3.3 installed on IIS6, php5.1.2(cgimode) and mysql 5.0.20.   

If a brand new user registers on my postnuke, logs into postnuke and then clicks the link to go to my coppermine install (via pncpg), the user is taken to the coppermine login screen.  This only happens the first time.  If they click the link a second time, they are automatically logged into coppermine.  I have tried this using Opera and IE, no difference.  I've done it multiple times, so it is reproducable.

Any ideas how to fix this?

Thanks
Keith

[casNuy]

What are your settings within pnCPG ?

Cas

[Keitht]

Location : www.(mydomainname).com/CPG
coppermine db:cpg
coppermine table prefix:cpg145
open app full screen is checked
language: english
theme: default
create postnuke user in pnCPG is checked
Use dynamic data to store password y/n is checked
Send password by email y/n is NOT checked
make useralbum when creating user y/n: n
Name of coppermine album table : (this field is empty)
create guest account, allow unregistered (y/n) is NOT checked
Use original coppermine guest account (y/n): n
update coppermine users from postnuke is NOT checked
user table for postnuke: pn_users
user table for coppermine: cpg145_users
postnuke home (include trailing slash): /inetpub/wwwroot/
host for database name: 127.0.0.1
DB user for host: (my_user_name)
password db user: (my_password)


Keith

[Keitht]

I'm trying to pinpoint the problem.  I've enabled debug mode and display notices in Coppermine.  I created a test user in postnuke.  If I login into postnuke as that test user and click the link to coppermine, it takes me to the coppermine login page.  At that point, the test user exists in the coppermine user table and the _CPGPWD field is populated in the test users postnuke record.  If I hit the back button, then click the coppermine link again, the test user is automatically logged into coppermine.
  One thing that I noticed after enabling debug, which may be relevant.  I went into pn_index and increased the time delay in the refresh tag to 600 seconds, so I could view the debug information immediately before the user was either redirected to the login page, or into coppermine.
  When it fails to work properly, the queries array only has 13 entries in it (0-12).  That 13th entry is the select user_id, user_name, user_password from cpg.cpg145_users where user_name='username' and BINARY user_password='somevalue' and user_active='YES'.  If I take that query and run it manually, it returns zero rows.
  When it works properly, the queries array has 18 entries in it.  Up until the 13th entry, they match pretty closely.  The 13th entry is the same, except for the user_password value in the where clause.  It's a different value, and if I run this query manually, it returns one row.

I'm going to try to track down why it's using a different value in that password condition.

Keith

[Keitht]

Oops.  For the statement about the refresh delay, that should be index_pn.php, not pn_index.

Keith

[Keitht]

I've drilled down further.  The problem seems to be occurring in the pnCPG_user_main function in pnuser.php, in the following lines of code:

if ($usedud == 1){
   // verify password exist
        $check_pwd = pnUserGetVar("_CPGPWD",$uid);
   // if not exist, create one
   if ($check_pwd != ""){
      $dudpwd = base64_encode(pnUserGetVar("_CPGPWD",$uid)) ;
   }else{
      $dudpwd1 = pnCPG_ranpass() ;
      $ok = pnUserSetVar("_CPGPWD",$dudpwd1);
      $dudpwd = base64_encode(pnUserGetVar("_CPGPWD",$uid)) ;
   }
}
The first time a new user tries to access coppermine (_CPGPWD is null), it successfully creates a random password and populates _CPGPWD, but the following call to pnUserGetVar is returning nothing.  The second time, check_pwd is populated with the correct value from pnusergetvar.

Keith

[Keitht]

I found a way to work around the problem.  I don't know if it's a "good" solution or not, but it seems to work.
  I took a quick look in pnusergetvar and pnusersetvar.  It looks like pnusergetvar only loads the variables if they haven't been loaded already.  Pnusersetvar does not force a reload of the variables.  So, if you read a var, set a var and then try to read the update - it doesn't see the change.  Causing another request will fire up another instance of php, which will force a reload of the vars.
Looking at ~line 325 in pnUser.php, you'll see this:
    // Get this user's variables if not already obtained
    if (!isset($vars[$uid])) {
        $vars[$uid] = pnUserGetVars($uid);
    }

I commented out the condition, forcing a reload of data everytime pnusergetvar is called, and everything works as expected now.  If this is really a bug, a better fix would probably be to reload the data anytime pnusersetvar is called.

Keith