application does not initialize if unauthorized user

I am having the same issue. My embedded phpgedview only works if I clear the cookies before each login. If I do not, the iframe which is supposed to contain it, is completely blank. After clearing the cookies and logging in, the drupal and phpgedview work famously together.

I wonder if this is drupal, phpgedview, a web server or a browser issue? Or a combination of all or some?

Any help/comments/suggestions would be greatly appreciated.

Thanks!

Actually, if you have refered to my post here http://drupal.org/node/109166 you will see I had the same problem and fixed it by changing that embedded path to something different than the installed path.

*cough* thought I had fixed it, just went to try and get into it and now I am having the same problem again, changed it to external and still not logged in, go figure, so I can't help you except to add my woe's.

irishlt, you are probably having the exact same issue I am with cookies not being set or read correctly by either druapl or phpgedview. If you clear your cookies and log in, you will have no issues accessing drupal and phpgedview (embedded or not). But if you log out and then back in, drupal will work no problem but phpgedview will no longer come up.

My gut tells me that maybe drupal.php is not properly handling the cookies set by drupal or vice versa where drupal is not properly setting the login cookie. My knowledge of PHP, cookies and the like is not very extensive so I would not hold your breath waiting for me to find the issue. :p

I don't have time to dig into this right now, but it looks like all the problems are related to logging in one way and then trying to log out and log back in as someone else. I'm not sure I understand why anyone is doing this in the first place. If you log in and stay logged in as the same person things seem to work fine. That's the way I use it and have never had any of these problems.

The issue is that both Drupal and PhpGedView use both sessions and cookies to keep track of who is who, and both the Drupal and PGV sessions and cookies need to get updated if you change identities, and that starts to get complicated. If you log in in Drupal and go to PGV using the internal path, and keep the same identity as you go back and forth, I am pretty sure everything is fine.

I am not sure I have any solution for changing identities. There are things I can do on the Drupal side, but very limited options on the PGV side since PGV was not designed in a way that really makes it possible. There may be ways to do this, but as I say, I don't have time to dig into this right now so it will have to wait until I have more time (or someone else figures out a way to do it and posts it here.)

And I am not experiencing the problem for anonymous users either, they work fine for me.

I will try to dig into this when I can, it just won't be right away. Sorry!

Thanks for the response KarenS. We understand you are busy, but my issue is not when switching users because I agree, why would anyone. I cant speak for anyone else, but my issue is if I log in with one account, then log out and log back in with the same account. It appears the cookie gets reset upon log out but not set back up when logging in.

So here's what I've done. I setup a rudimentary block which displays all the time (logged in and logged out). The contents of the block displays the value in the cookie "pgv_permissions", base64 decoded of course. Here is the code I used if anyone is interested in trying this themselves: (the input format for the block must obviously allow PHP code.)

<?php
$permissions = @unserialize(@base64_decode($_COOKIE['pgv_permissions']));
print 'def_canedit = ' . $permissions['def_canedit'] . '<br/>';
print 'def_canadmin = ' . $permissions['def_canadmin'] . '<br/>';
print 'def_theme = ' . $permissions['def_theme'] . '<br/>';
print 'def_rootid = ' . $permissions['def_rootid'] . '<br/>';
print 'def_verified = ' . $permissions['def_verified'] . '<br/>';
print 'def_verified_by_admin = ' . $permissions['def_verified_by_admin'] . '<br/>';
print 'def_contact_method = ' . $permissions['def_contact_method'] . '<br/>';
print 'def_gedcom = ' . $permissions['def_gedcom'] . '<br/>';
print 'def_language = ' . $permissions['def_language'] . '<br/>';
print 'def_upass = ' . $permissions['def_upass'] . '<br/>';
print 'def_create_user = ' . $permissions['def_create_user'] . '<br/>';
print 'post_user = ' . $permissions['post_user'] . '<br/>';
print 'post_email = ' . $permissions['post_email'] . '<br/>';
?>

This is how the output looks:

def_canedit = edit
def_canadmin = no
def_theme =
def_rootid = I1
def_verified = yes
def_verified_by_admin = yes
def_contact_method = messaging2
def_gedcom = genealogy
def_language = english
def_upass =
def_create_user = yes
post_user = <username>
post_email = <email>

Now, I log out and clear all cookies from the browser. Refresh the page and the block should display all blanks. Login as some user, and the block will then become populated with proper values and everything should work, including phpgedview. Now, log out and you will notice that the values in the block again become blank. But then login with that same user name or any other username, and the block values will remain completely blank and phpgedview will not work. :S

So after some investigation, I found a function in phpgedview.module called phpgedview_unset_cookies() and after commenting the entire contents of the function, then doing the exact same procedure as above, the second time you log in whether the same user or not, phpgedview still works. Unfortunately, because the cookie was not ever reset, the values of the phpgedview cookie and hence the custom block, remain as the first user logged in. This is a very hacked way around this issue, and maybe with a little more work I will be able to figure it all out and the second time you log in, the cookies values will update with the current users info. :D

I guess I was a little quick to post that last, but I may have found the workaround. It works for me anyway but I dont know what other affects it may have, if any.

Open phpgedview.module and find this string:

function phpgedview_set_cookies($account, $reset = FALSE) {

Once you've found it, replace the word FALSE with the word TRUE so that it looks like this:

function phpgedview_set_cookies($account, $reset = TRUE) {

Save, upload and give it a try. Let me know how that works for you and maybe KarenS when she has time (no rush) could give a little insight into exactly what changes and what other affects this has on durpal and phpgedview as a whole.

Cheers!

I'm having the exact same problem here.... Now, I've looked at the code and found these lines. First, in phpgedview.module:

function phpgedview_set_cookies($account, $reset = TRUE) {
  if ($account->uid > 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
    ....
    setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');

Then, in drupal.php:

if (!$permissions = @unserialize(@base64_decode($_COOKIE['pgv_permissions']))) {
  exit;

Now, if I have no cookies and am an anonymous user in drupal (uid = 0), then there will be no cookie with pgv_permissions set. Thus, drupal.php will exit right away. How is anonymous logon from drupal to phpgedview supposed to work? Looking at this code (5.1.0-1.x), it just cannot work.

I'm not entirely sure of a fix for anonymous access as the phpgedview I have installed is only for logged in users, not anonymous. But a little more to go on my last, I have modified the phpgedview.module differently than what I had said before. So, if you want to try this out, I would start with a fresh copy of phpgedview.module so that no mods or editing has been done. I am going to include my version as an attachment because it would take me a bit to explain what to change and where to change it. So if you want to see the changes made, then just open a fresh copy and this copy in some sort of file comparing software and it will show you the differences.

The main differences in my version are lines 84-85, 800-801, 883-884 and if you will notice line 905 is now back to the way it originally was when you first download the module.

I see your changes and I do understand them. Basically, you leave all pgv cookies in place, unless there is a new logon to phpgedview. However, that does not fix the case where a user without any pgv cookies goes to phpgedview.

The case remains that if an anonymous user without any pgv_* cookies goes to phpgedview.module and then to drupal.php, he does not get any pgv_* cookies from phpgedview.module, and then drupal.php just does an exit().

You can test your code by logging out of drupal, then removing all cookies set by your site (especially pgv_permissions) and then navigating to http://yoursite/phpgedview/ (or whatever you use). BTW, I'm using Drupal 5.1 + the latest version of the phpgedview module. Your module code did not work for me; I assume you're using 4.7 or similar.

Yes sorry, I should have mentioned the phpgedview.module I attached was for 4.7 as that is what I am running. But, the changes I've made will work with 5.x as well. The easiest way is probably to go by line number which is slightly different in 5.x. In the 5.x module, modify lines 74, 789, 871 and 892 to the same as their respective lines 84-85, 800-801, 883-884 and 905, in my first attached module. OR just look at the second module I've now attached which is version 5.x of phpgedview.

Now, to deal with the anonymous access. Modify what you included before:

    if ($account->uid > 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
    ....
    setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');

To this:

    if ($reset || !isset($_COOKIE['pgv_permissions'])) {
    ....
    setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');

The only change is the first line which simply gets rid of the check for what user is logged in, and sets permissions anyway based on the user map within the phpgedview database. This in theory, should not give anonymous users any access but to view the phpgedview but who knows. I tested it very briefly on my installation and anonymous users were granted viewing access only rather than just getting a blank page. Give it a try, and post your results here. Hope this helps!

Ok, that seems to work. I'm slowly getting this to actually work. My next issue. In previous versions, all cookies were set using setcookie. Very good. However, the latest version uses phpgedview_set_value(). If you look at it, this is what it does:

function phpgedview_set_value($key, $value) {
  $GLOBALS['phpgedview']['permissions'][$key] = $value;
}

Instead of setting the cookie, it sets a global variable. There is no way that that ever gets into the iframe. My solution is to add a line to that:

function phpgedview_set_value($key, $value) {
  $GLOBALS['phpgedview']['permissions'][$key] = $value;
  setcookie($key, $value, 0, '/');
}

No, thats exactly how it gets into the cookie. The set_value is called first to actually...well...set the value, then if you will notice as in the code from above:

setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');

this actually converts the keys and values ($GLOBALS['phpgedview']['permissions']) into base64 for security reasons (as the cookie contains usernames and passwords) and on the other end is converted back into regular key and value, and used by phpgedview for login and permissions. If you add the line you stated, your information will be stored in a cookie, which will be insecure, where it is already stored in a cookie, just not legible.

But I am not entirely sure as to what the problem here is. Is the module still not performing the way it should after the last few modifications?

Ok, I understand how the array in a cookie works. However, I still have two issues with the latest module:
- after logout of a user, phpgedview was no longer accessible. I had to clear the pgv_permissions cookie. The problem was in the line in phpgedview_unset_cookies():
setcookie('pgv_permissions', serialize(array(), 0, '/');
This conflicts with the line in drupal.php:
if (!$permissions = @unserialize(@base64_decode($_COOKIE['pgv_permissions']))) {}
Because in this code, unserialize returns an empty array, it will trigger the if{} statement and exit. I've changed the setcookie line to:
setcookie('pgv_permissions', base64_encode(serialize(array($GLOBALS['phpgedview']['permissions']))), 0, '/');

- phpgedview doesn't automatically create the users, but I finally figured this out as well. You need to login, go to phpgedview, logout, login again and go to phpgedview again to create the user. The reason is that the value of post_user is set @ login, but a user is not entered into the phpgedview_user_map table, until he first goes to phpgedview. But then, the value of post_user is still empty. So, he needs to logon again to get post_user filled and then go to phpgedview again to get his user created.

- Also, if you look at the current code in phpgedview_embedded_page(), I can see at least 2 variables which are never defined: $uid and the $username variable inside if ($uid > 0) {} is only defined in certain occasions, but that code is unreachable anyway. The user will never get to the edituser page.

Finally, I've modified phpgedview_set_cookies() to the code below to make sure that an anonymous user ends up with an empty pgv_permissions cookie and also unset post_user, def_can_edit, etc...:

function phpgedview_set_cookies($account, $reset = FALSE) {
   if ($account->uid > 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
   ....
        setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');
    } else if ($account->uid == 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
        phpgedview_unset_cookies();
    }

Okay, for the first issue when a user logs out, anonymous access is not granted. I'm assuming when you said you changed the setcookie line to this

setcookie('pgv_permissions', base64_encode(serialize(array($GLOBALS['phpgedview']['permissions']))), 0, '/');

you mean the setcookie line in the phpgedview_unset_cookies(). If so, you are correct, but that is the only change you would need to do, to allow for anonymous access whether first visiting the page, or after logging out of an authenticated user. So all that extra code you entered here:

function phpgedview_set_cookies($account, $reset = FALSE) {
   if ($account->uid > 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
   ....
        setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');
    } else if ($account->uid == 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
        phpgedview_unset_cookies();
    }

is most likely not required. But if it ain't broken, then don't fix it.

Second, the creation of users can be fixed quite easily as well. First off, we need to edit the phpgedview.module to get the username from the global $user instead of the $account variable. This way the logged in username is ALWAYS correct.

function phpgedview_set_cookies($account, $reset) {
	global $user;            // *** ADDED
  
  if ($account->uid > 0 && ($reset || !isset($_COOKIE['pgv_permissions']))) {
    $map = phpgedview_user_map();
    // $username = $map[$account->uid];            // *** COMMENT OUT
    $username = $user->name;            // *** ADDED
    
    phpgedview_unset_cookies();

   	// set pgv_user so that they will be logged in in gedview
	  phpgedview_set_value('post_user', $username);
	  phpgedview_set_value('post_email', $account->mail);
    phpgedview_set_value('post_canedit', $canedit);
	
    //setup the  post_config variables as cookies so postgedview doesnt need to read them
		phpgedview_set_value('def_canadmin', variable_get('phpgedview_def_canadmin', 'no'));
		phpgedview_set_value('def_canedit', variable_get('phpgedview_def_canedit', 'access'));
		phpgedview_set_value('def_rootid', variable_get('phpgedview_def_rootid', ''));
		phpgedview_set_value('def_verified', variable_get('phpgedview_def_verified', 'yes'));
		phpgedview_set_value('def_verified_by_admin', variable_get('phpgedview_def_verified_by_admin', 'yes'));
		phpgedview_set_value('def_create_user', variable_get('phpgedview_def_create_user', 'yes'));
		phpgedview_set_value('def_language', variable_get('phpgedview_def_language', 'english'));
		phpgedview_set_value('def_upass', variable_get('phpgedview_def_upass', ''));
		phpgedview_set_value('def_gedcom', variable_get('phpgedview_def_gedcom', ''));
		phpgedview_set_value('def_contact_method', variable_get('phpgedview_def_contact_method', 'messaging2'));
		phpgedview_set_value('def_theme', variable_get('phpgedview_def_theme', ''));
    setcookie('pgv_permissions', base64_encode(serialize($GLOBALS['phpgedview']['permissions'])), 0, '/');
  }
}

You should notice 3 changes in the above function: the addition of "global $user;" at the top to get the user's values, the commenting out of the original "$username = $map[$account->uid];" and then the addition of "$username = $user->name;" to get the username properly every time.

Next we have to edit drupal.php, because I don't know if you get the same errors when a new users first attempts to access drupal, but I get about a dozen errors because some variables are not defined for new user creation, so here I am just going to ensure these variables exist, but they will be completely empty just to stop the errors from popping up. I've included the part of the file that I edited and I commented the lines I've added with "// *** ADDED" and the lines I've commented out with "// *** COMMENT OUT", as they never seem to do anything for me:

<?php

...

if (!empty($post_user)) {
  // need to add the user into gedview - but only if def_create_user says its ok
  if (!getUser($post_user) and ($def_create_user == "yes") ) {
    $newuser = array();
    $newuser["username"] = $post_user;
    // $newuser["firstname"] = $post_firstname; // *** COMMENT OUT
    // $newuser["lastname"] = $post_lastname; // *** COMMENT OUT
    $newuser["firstname"] = ""; // *** ADDED
    $newuser["lastname"] = ""; // *** ADDED
    $newuser["canedit"] = array();
    if ($def_canedit == "yes") {
      $newuser["canedit"][$def_gedcom] = "yes";
    } else {
      $newuser["canedit"][$def_gedcom] = "";
    }
    $newuser["gedcomid"] = array();
    $newuser["gedcomid"][$def_gedcom] = '';
    $newuser["rootid"] = array();
    $newuser["rootid"][$def_gedcom] = $def_rootid;
    $newuser["canadmin"] = $def_canadmin;
    $newuser["email"] = $post_email;
    $newuser["verified"] = "yes";
    $newuser["verified_by_admin"] = $def_verified_by_admin;
    $newuser["pwrequested"] = "";
    $newuser["theme"] = $def_theme;
    $newuser["language"] = $def_language;
    $newuser["reg_timestamp"] = date("U");
    $newuser["reg_hashcode"] = "";
    $newuser["loggedin"] = "N";
    $newuser["sessiontime"] = 0;
    $newuser["contactmethod"] = $def_contact_method;
    $newuser["password"] = crypt($def_upass);
    
    $newuser["visibleonline"] = ""; // *** ADDED
    $newuser["editaccount"] = ""; // *** ADDED
    $newuser["default_tab"] = ""; // *** ADDED
    $newuser["comment"] = ""; // *** ADDED
    $newuser["comment_exp"] = ""; // *** ADDED
    $newuser["sync_gedcom"] = ""; // *** ADDED
    $newuser["relationship_privacy"] = ""; // *** ADDED
    $newuser["max_relation_path"] = ""; // *** ADDED
    $newuser["auto_accept"] = ""; // *** ADDED
    
    addUser($newuser, "added");
  }

...

Now, I hope I didn't leave anything out, so give it a try if you want, and let me know. Keep in mind, I was working with 4.7 but like before, the files are not much different. The changes should remain the same, I would simply located the same position and make the changes yourself. Copy and paste the lines I've added and manually comment out the lines as required.

I added your changes to my original changes and all is now working as it should be. The only exception is that when adding a new user under phpGedView, he/she is always granted admin rights. I've checked the value of def_canadmin in drupal.php and it's set to no. It's also set to no in the newuser array. But, when I check the database after the user was created, it's set to yes.
I couldn't find the cause, but added an extra SQL query in drupal.php after every user creation to make sure that it's set to 'N' in the database.

Someone else was experiencing the same issues with all users being created as admin users, so I'm posting my diff to drupal.php here.

--- drupal.php.org      2007-03-04 19:41:17.654334362 +0100
+++ drupal.php  2007-02-18 16:41:11.066125943 +0100
@@ -115,6 +115,10 @@
   if (getUser($post_user) and ($admin_ver == "yes")) {
     $sql = "UPDATE ".$TBLPREFIX."users SET u_loggedin='Y', u_sessiontime='".time()."' WHERE u_username='$post_user'";
     $res = dbquery($sql);
+    if ($post_user != "admin") {
+        $sql = "UPDATE ".$TBLPREFIX."users SET u_canadmin='N' WHERE u_username='$post_user'";
+        $res = dbquery($sql);
+    }
     AddToLog("Drupal Login Successful ->" . $post_user ."<-");
     $_SESSION['pgv_user'] = $post_user;
     $url = $path; // . session_name() ."=". session_id();

Hey riddles, thanks for the phpgedview.module_0.txt ..it fixed the problem I was having.

I tried the last bit of code that you posted and not sure if it was supposed to do this or not but.. when I went to PhpGedView using the main admin account it changed it to a non admin account.

Since I only had one account, to fix it I had to reupload the original drupal.php, create another account, let it get admin rights and then change the admin rights of the original admin account.

Is there any way to fix that bit of code that you posted to make it only change new users instead of current users?

mattjp03, I had a similar issue. Look at the last bit of code from riddles; I changed a line of code to refer to my Drupal User Name instead of "admin" so that the line looks like this (insert your User Name as indicated):

...
if ($post_user != "Your_Drupal_User_Name") {  //*** MODIFIED- mac : changed from "admin"
...

This kept it from changing me back to a non-admin. Hope this helps.

Thanks macunni, that fixed the problem.

I guess so far everything is working fine on my end now. Between all of the fixes everybody has submitted and all of the great help all of you are.. this Drupal and PhpGedView merge is looking alot better than all of the other choices out there. Hopefully the "Error when user 1st accesses embedded phpgedview" issue will be resolved soon.

Thanks everybody!

mattjp03, if you look at my post (#18) there is a basic fix for the errors that appear when a user first attempts to access phpgedview embedded. The errors are merely caused by variables not being defined. What I have done is ensure they are defined, even if defined with a blank.

The changes that need to be made are in the last code snippet for drupal.php. Have a read of #18 and you'll find it.

Cheers!

Thanks chandlben, I missed that part. I did everything else but that.. not sure why.

Anyways, everythings fixed now. :-)

I have been following this issue and wonder if everybody is all sorted?

In particular does anybody have a setup that is purely private requiring login to access pgv and if so is it running successfully?

I think with mine I may have made so many changes I can't even track them so am looking at re-installing from scratch with that in mind, would a really kind soul compile a short list of the relevant changes needed in the mod to do this? As there are so many ittle bit's I am not sure what is required and what isn't.

Looking forward to getting pgv working again, thanks, Rhonda

I thought I had this resolved, but I don't. I've tried the fixes above, but it still does not work correctly. I don't think this is a different issue than what this started out as, but if it is, I don't mind logging this as a separate issue. I am using Drupal 5.1 and PHPGedView 5.x-1.0 module.

The problem is anonymous users/visitors can not view the embedded phpgedview program. The external seems to work fine. I've tried this from several different computers using FF and IE6. I've reinstalled drupal and phpgedview (module and app) several times (in a test area). Cleared cookies, cache, double checked settings, used "fixes" mentioned above and not, and other stuff. Still this issue persists. However, I can view KarenS's site just fine, so I'm not ruling out it's something I'm doing wrong.

Also, I noticed that the phpgedview_user_map table is growing with entries of uid = 0 and pgv = null. I think this is a result of implementing the code above, but I haven't verified this yet.

I want to try out a few more tests, but I plan to roll this out on my live site even if I have to use the external option. I think this is a great module and hope KarenS is able to continue developing it.

I've rechecked mine and it seems to be doing the same thing as well. I've also reinstalled everything and applied the fixes again and the same thing happens.

So far everything except the anonymous viewing works. I didn't notice this before because I always logged in to Drupal before I went to the family tree.

If anybody gets that fixed, can you attach the updated drupal.php and phpgedview.module that's currently working?

macunni and mattjp03, I'm not sure why your anonymous access is not working. Once enabled in the Drupal Admin->Access Control it works fine for me. I assume you've already done so, but make sure anonymous users have viewing rights in the Access Control of drupal.

dixieau, I've been trying to get a compiled list of all the tid bits but it's very time consuming as I don't even know which ones are necessary and which ones aren't. I might have it for you shortly.

Ben, thanks for taking the time to help. Just to be sure I checked the Access Control again and it is checked for anonymous and authenticated to view phpgedview. I installed a fresh copy of Drupal to rule out module conflicts and tried again with the same results. I also re-submitted each configuration page in case something didn't "take." I even turned off Clean URLs

I just can not understand what the problem could be, and it's so frustrating. Everything seems to work fine except that phpgedview will not display embedded. I get the menu across the top of the embedded pane, and if I click on them they change as though it is doing something. I just do not see the GED data. It's not just one browser or one computer, it's all of them (FF, IE6, and Opera). I also checked IE6 to be sure iframes were enabled. Could it be the web host? A .htaccess setting? I'm really grabbing at straws.

I just don't know what else to try. I'm confident I followed the set-up instructions correctly. I can not think of any other setting or option to tweak. I'll keep watching these support posts/requests and hope some fix turns up.

Thanks again.

Does anyone have an updated phpgedview.module file with ALL of these changes that need to be made for version 5?

I just committed a fix that I hope takes care of most of the bugginess of cookies and anonymous users. Sorry for the long delay in getting to this. I've been buried in other projects.

Guess I am kind of new to this - how do I get the fix if has been commit?

Karen,

Thank you for the update. I did some quick tests and it appears the issues I had are resolved. If something else pops up I'll post again. Your time and efforts are greatly appreciated. This module is exactly what I've been hoping for to share my genealogy research with other family members. Thanks again.

Cindi,

Go to the modules page and download the development version that applies to your version of Drupal.