I have one user comming to watch my pedigree tree. She can log in, but every time she tries to chance page in the tree, she is logged out, and sent back to the login screen. She's using MS Explorer 6, and seem to have the same settings as I have in my Explorer. Every other user have no problems like this. Anyone have a clue, as to what could cause this weird behavior, or have simular experiences ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I set my firewall to block cookies, I can not do certain admin functions.
When I allow cookies again, the cookie is written and the admin functions, that I could not do before, are working again.
I discussed this with Roland. According him, the pgv is not writing cookies, so it might be PHP on the server.
But I have other sites on my server (also partly with php), that are not writing the cookies.
Then my conclusion is that pgv writes the cookies, while it was my understanding that it was only working with the session posts in the ./index/ dir.
Jans
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
4. Check your cache and your cookie store again, and refresh/update and find a PHPSESSID cookie from Lars' domain.
According to PHP documentation there exists two methods to propagate a session id: Cookies and URL parameter.
The session module supports both methods. Cookies are optimal, but because they are not always available, PHP also provide an alternative way. The second method embeds the session id directly into URLs.
Best regards,
Arne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is exactly the same problem I've experienced. It definitely is a cookie problem related to the client side. I've tried it on the same machine with different browsers. IE didn't work, Netscape did. OS was Windows 98, IE is 6 SP1. OS may have something to do with it. I had two others users experience the problem as well. One had another machine to use where it was working properly.
THe user is able to log in, but when they click on a link, they get the login page again. The browser isn't sending back the session stored in the cookie. If you put the session id in the URL it works.
Is there some kind of way to get all the URLs generated to include the session id in it? Turning off cookies on the server (session.use_cookies) doesn't work and really isn't a good solution anyway? Suggestions? Anyone?
In PGV versions prior to ver. 2.65.2 a session-id cookie was set in the client side Internet cache.
In PGV versions 2.65.2 and 2.65.3 such a session-id cookie are not set in the client side Internet cache.
According to John Finlay, nothing has been changed in PGV in respect to setting such a session-id cookie on or off, so at this time apparently nobody involved in the PGV project has any knowledge about what causes this cookie to be set or not to be set.
The above mentioned session-id cookie (Cookie:user@domain.com/) has a content like this:
Cookies of the type mentioned above are not to be confused with the session-cookies, which are saved to the session.save_path. The latter mentioned session-cookies (sess_1c629eb1cb4c9498e5243eaec6b1caa4) has a content like this:
It recently was discovered that the language editor couldnt be used when run from the PHPLaunch. Whenever an authenticated user tried to use the tool, the user was asked to login. And even when the user was authenticated again, the access was still refused.
When I studied the communication between the PHPLaunchs WebBrowser component and the HTTPServer component, it appeared that the WebBrowser component at a specific point in the program issued a GET command, without specifying the PHP session-id, and in doing this it was forcing the HTTPServer to issue a Set-Cookie command.
This Set-cookie command caused a new session-cookie to be set in the session.save_path which didnt contain any information about the authenticated user, hence the user was asked to login to get authenticated.
When I tried to access the PGV in the PHPLaunch from an external web browser like MSIE6 or Mozilla FireBird, the Set-Cookie condition never occurred, and no trouble was experienced in using the language editor.
Now, this finding was confusing, because the PHPLaunchs WebBrowser component is virtually identical to the MSIE6 Core engine. However, I tried to replace the WebBrowser component with a similar Active-X based Mozilla Gecko engine but this engine also failed.
Next I tried to access PGV at a Website on the Internet, from custom made browsers based on the previous mentioned WebBrowser components, they also failed, and this result was too bad, because these components didnt feature any interface to cookie management.
At this point I discovered that older versions of PGV didnt have this problem, as well as I discovered that the session-id cookie in the client side Internet cache did all the difference. That is, if a valid session-id cookie existed in the client side Internet cache, none of the PGV versions had problem with accessing the language editor. And here it made no difference, if this session-id cookie was set by a different version of PGV.
Unfortunately it wasnt discovered what in PGV made the cookie setting change behaviour, instead the problem was solved, by propagating the session-id in the URL when calling the language editor functions.
The reason I tell you this is, that the problem you describe, in a sense is similar to the problem I have described here.
Perhaps a detailed comparison of version 2.65.1 and version 2.65.2 can reveal what makes the difference however, dont expect the PGV developers to pay any interest to this problem: To them, even the current and error prone version 2.65.3 are long forgotten history. To the developers only version 3.0 alpha exists ;-(
Best regards,
Arne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you will send me a link to your site along with a temporary username and password, I will try to figure out why it is not working for you.
Please send it to yalnifj at sourceforge.net.
Also could you please post back to this forum what version of PHP you are using. The version of Apache and operating system you are hostin PGV on could also be helpful.
Thanks,
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have one user comming to watch my pedigree tree. She can log in, but every time she tries to chance page in the tree, she is logged out, and sent back to the login screen. She's using MS Explorer 6, and seem to have the same settings as I have in my Explorer. Every other user have no problems like this. Anyone have a clue, as to what could cause this weird behavior, or have simular experiences ?
I should say, that I tried deleting this user, create a new one, and even gave her new username and password .. nothing seems to help.
When I login a cookie is placed in my cookie dir on my pc.
When I delete the cookie I'm asked to login again. This probably correspond to the situation where cookies are not accepted.
Best regards,
Arne
Hi all,
I think this is certainly a cookie matter.
When I set my firewall to block cookies, I can not do certain admin functions.
When I allow cookies again, the cookie is written and the admin functions, that I could not do before, are working again.
I discussed this with Roland. According him, the pgv is not writing cookies, so it might be PHP on the server.
But I have other sites on my server (also partly with php), that are not writing the cookies.
Then my conclusion is that pgv writes the cookies, while it was my understanding that it was only working with the session posts in the ./index/ dir.
Jans
Hi Jans
Yes, I suggested cookies because I think this is a cookie problem.
Try this experiment:
1. Clear your Internet browser cache.
2. Make sure no cookies exists from Lars' domain, or delete it if it exists.
3. Visit http://www.boriths.dk/family/
4. Check your cache and your cookie store again, and refresh/update and find a PHPSESSID cookie from Lars' domain.
According to PHP documentation there exists two methods to propagate a session id: Cookies and URL parameter.
The session module supports both methods. Cookies are optimal, but because they are not always available, PHP also provide an alternative way. The second method embeds the session id directly into URLs.
Best regards,
Arne
Has anyone figured out this problem?
This is exactly the same problem I've experienced. It definitely is a cookie problem related to the client side. I've tried it on the same machine with different browsers. IE didn't work, Netscape did. OS was Windows 98, IE is 6 SP1. OS may have something to do with it. I had two others users experience the problem as well. One had another machine to use where it was working properly.
THe user is able to log in, but when they click on a link, they get the login page again. The browser isn't sending back the session stored in the cookie. If you put the session id in the URL it works.
Is there some kind of way to get all the URLs generated to include the session id in it? Turning off cookies on the server (session.use_cookies) doesn't work and really isn't a good solution anyway? Suggestions? Anyone?
This is another thread describing the same problem.
http://sourceforge.net/forum/forum.php?thread_id=1005052&forum_id=185165
BTW, the other user is using Windows ME.
Hi D Michel
In PGV versions prior to ver. 2.65.2 a session-id cookie was set in the client side Internet cache.
In PGV versions 2.65.2 and 2.65.3 such a session-id cookie are not set in the client side Internet cache.
According to John Finlay, nothing has been changed in PGV in respect to setting such a session-id cookie on or off, so at this time apparently nobody involved in the PGV project has any knowledge about what causes this cookie to be set or not to be set.
The above mentioned session-id cookie (Cookie:user@domain.com/) has a content like this:
PHPSESSID
1c629eb1cb4c9498e5243eaec6b1caa4
domain.com/
1536
2554816128
29619307
3783050160
29619290
*
Cookies of the type mentioned above are not to be confused with the session-cookies, which are saved to the session.save_path. The latter mentioned session-cookies (sess_1c629eb1cb4c9498e5243eaec6b1caa4) has a content like this:
GEDCOM|s:11:"family.ged";cart|a:0:{}CLANGUAGE|s:6:"danish";pgv_user|s:5:"snake";usertime|i:1076569646;timediff|i:1;
It recently was discovered that the language editor couldnt be used when run from the PHPLaunch. Whenever an authenticated user tried to use the tool, the user was asked to login. And even when the user was authenticated again, the access was still refused.
When I studied the communication between the PHPLaunchs WebBrowser component and the HTTPServer component, it appeared that the WebBrowser component at a specific point in the program issued a GET command, without specifying the PHP session-id, and in doing this it was forcing the HTTPServer to issue a Set-Cookie command.
This Set-cookie command caused a new session-cookie to be set in the session.save_path which didnt contain any information about the authenticated user, hence the user was asked to login to get authenticated.
When I tried to access the PGV in the PHPLaunch from an external web browser like MSIE6 or Mozilla FireBird, the Set-Cookie condition never occurred, and no trouble was experienced in using the language editor.
Now, this finding was confusing, because the PHPLaunchs WebBrowser component is virtually identical to the MSIE6 Core engine. However, I tried to replace the WebBrowser component with a similar Active-X based Mozilla Gecko engine but this engine also failed.
Next I tried to access PGV at a Website on the Internet, from custom made browsers based on the previous mentioned WebBrowser components, they also failed, and this result was too bad, because these components didnt feature any interface to cookie management.
At this point I discovered that older versions of PGV didnt have this problem, as well as I discovered that the session-id cookie in the client side Internet cache did all the difference. That is, if a valid session-id cookie existed in the client side Internet cache, none of the PGV versions had problem with accessing the language editor. And here it made no difference, if this session-id cookie was set by a different version of PGV.
Unfortunately it wasnt discovered what in PGV made the cookie setting change behaviour, instead the problem was solved, by propagating the session-id in the URL when calling the language editor functions.
The reason I tell you this is, that the problem you describe, in a sense is similar to the problem I have described here.
Perhaps a detailed comparison of version 2.65.1 and version 2.65.2 can reveal what makes the difference however, dont expect the PGV developers to pay any interest to this problem: To them, even the current and error prone version 2.65.3 are long forgotten history. To the developers only version 3.0 alpha exists ;-(
Best regards,
Arne
If you will send me a link to your site along with a temporary username and password, I will try to figure out why it is not working for you.
Please send it to yalnifj at sourceforge.net.
Also could you please post back to this forum what version of PHP you are using. The version of Apache and operating system you are hostin PGV on could also be helpful.
Thanks,
--John