I am unable to connect to my newly installed PhpGedView with the GDBI java editor. PGV runs on a w2k machine, and I am using the GDBI editor from another w2k machine.
These are connected by an internal network, and I have tried using both internal IP and DNS name in the URL field. For example:
Apache is using basic auth, so I have also tried supplying the basic auth login data in the URL field. I have tried both index and mysql, but there is no change. It seems that I am not even getting the error messages that I looked are in the gdbi.php file.
Any hints for debugging my connection attempts, I would strongly suspect some basic fault here?
Regards,
.brum
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-25
Soeey for the mess with that link, I did not know it would behave that way. Here is (hopefully) what I wanted to convey:
http: // pgv:pgv@192.168.0.2/phpgedview/
Regards,
.bjrn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was going to ask for a temporary user, but you say it is an internal network. You can try debugging by running from a command prompt window and then turning on all debugging. Cancel the Open Database window to get to the main window. Then press Help - Set debug - Set all, and close that window. Then press File - Open database and see if it prints some useful diagnostics in the command prompt window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-26
Daniel,
Thanks for the fast response. Here is some debugging:
This worked straight away, with the needed htaccess data in the url (http: // pgv:pgv @ 192.168.0.2/phpgedview/gdbi.php?action=version, so it is the same URL as used below).
- but starting GDBI editor form the command line gives this output:
H:\Documents and Settings\Brum1\Desktop\phpGedview GDBI client>java -jar gdbi-9-
pgv.jar http://pgv:pgv@192.168.0.2/phpgedview/gdbi.php pgv pgv_user test.ged
Using url: http: // pgv:pgv @ 192.168.0.2/phpgedview/gdbi.php
Using username: pgv
Using password: pgv_user
Using gedname: test.ged
IO Error: Server returned HTTP response code: 401 for URL: http: // pgv:pgv @ 192.16
8.0.2/phpgedview/gdbi.php
If a temporary user could help you help me, I would be more than happy to set it up for you (it is accessible from the Internet). How can I send this kind of data to you?
Regards,
.bjrn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To send email with the temp user account, if you use the SF web page, you can click on the user name, which takes you to the user's page, which has an email link.
That is the general rule, but I don't mind posting my Yahoo address because they have good spam filtering: dkionka@yahoo.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-26
Daniel,
401:
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"
I have seen this error message before, but the situation is much different. It is sending you an HTML page instead of the data it is expecting. You normally get that for every CGI command when things are not set up right.
I tried your URL, and I get 2 successful commands and then it fails. It does the version and connect commands, and gives you a PHPSESSID, but when it runs listgedcoms it gets the login screen.
Maybe John can help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that I just released a new version of GDBI. It doesn't fix the problem, but there is now a "verbose" option on the "set debug" page that shows the CGI output.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried this again, and I was able to log in! The trick was not specifying the gedcom name. That narrows down the bug to the listgedcoms action. (It doesn't run listgedcoms when it uses the default.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-13
Daniel,
Thank you very much for this! I also tried the same approach (without the gedcom name), and it works here also :). Gee, I truly thought I had tried that variant already before...
Best regards,
.brum
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am unable to connect to my newly installed PhpGedView with the GDBI java editor. PGV runs on a w2k machine, and I am using the GDBI editor from another w2k machine.
These are connected by an internal network, and I have tried using both internal IP and DNS name in the URL field. For example:
http://user:pass@192.168.0.2/phpgedview/, which works when pasted directly in the browser.
Apache is using basic auth, so I have also tried supplying the basic auth login data in the URL field. I have tried both index and mysql, but there is no change. It seems that I am not even getting the error messages that I looked are in the gdbi.php file.
Any hints for debugging my connection attempts, I would strongly suspect some basic fault here?
Regards,
.brum
Soeey for the mess with that link, I did not know it would behave that way. Here is (hopefully) what I wanted to convey:
http: // pgv:pgv@192.168.0.2/phpgedview/
Regards,
.bjrn
This sounds similar to this thread, but I thought we had resolved all the issues:
http://sourceforge.net/forum/forum.php?thread_id=988628&forum_id=102502
I was going to ask for a temporary user, but you say it is an internal network. You can try debugging by running from a command prompt window and then turning on all debugging. Cancel the Open Database window to get to the main window. Then press Help - Set debug - Set all, and close that window. Then press File - Open database and see if it prints some useful diagnostics in the command prompt window.
Daniel,
Thanks for the fast response. Here is some debugging:
- test from thread http://sourceforge.net/forum/message.php?msg_id=2439322:
You can test if your server is working properly by opening a browser and going to:
http://localhost/Ahnen/gdbi.php?action=version
This worked straight away, with the needed htaccess data in the url (http: // pgv:pgv @ 192.168.0.2/phpgedview/gdbi.php?action=version, so it is the same URL as used below).
- but starting GDBI editor form the command line gives this output:
H:\Documents and Settings\Brum1\Desktop\phpGedview GDBI client>java -jar gdbi-9-
pgv.jar http://pgv:pgv@192.168.0.2/phpgedview/gdbi.php pgv pgv_user test.ged
Using url: http: // pgv:pgv @ 192.168.0.2/phpgedview/gdbi.php
Using username: pgv
Using password: pgv_user
Using gedname: test.ged
IO Error: Server returned HTTP response code: 401 for URL: http: // pgv:pgv @ 192.16
8.0.2/phpgedview/gdbi.php
If a temporary user could help you help me, I would be more than happy to set it up for you (it is accessible from the Internet). How can I send this kind of data to you?
Regards,
.bjrn
Does anyone know what the 401 error implies?
To send email with the temp user account, if you use the SF web page, you can click on the user name, which takes you to the user's page, which has an email link.
That is the general rule, but I don't mind posting my Yahoo address because they have good spam filtering: dkionka@yahoo.com
Daniel,
401:
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"
Found at:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Regards,
Roland
Hi again,
I checked what effect taking away the basic authentication would have.
For me this did not change the end result, but now the error is more specific, here is the command line (w2k) output:
-------------------------
CGI error: action=listgedcoms: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Tran
sitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
full URL parameter:
action=listgedcoms&GEDCOM=test&PHPSESSID=caa05132e842239483d
9015d452682ce
Bad error message: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN
" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
------------------------
Would the "full URL parameter" perhaps indicate a misconfiguration of my Apache (1.3.23 on w2k)...?
Regards,
.bjrn
I have seen this error message before, but the situation is much different. It is sending you an HTML page instead of the data it is expecting. You normally get that for every CGI command when things are not set up right.
I tried your URL, and I get 2 successful commands and then it fails. It does the version and connect commands, and gives you a PHPSESSID, but when it runs listgedcoms it gets the login screen.
Maybe John can help.
There is a similar report in the GDBI forum:
http://sourceforge.net/forum/forum.php?thread_id=1126425&forum_id=102503
Note that I just released a new version of GDBI. It doesn't fix the problem, but there is now a "verbose" option on the "set debug" page that shows the CGI output.
I tried this again, and I was able to log in! The trick was not specifying the gedcom name. That narrows down the bug to the listgedcoms action. (It doesn't run listgedcoms when it uses the default.)
Daniel,
Thank you very much for this! I also tried the same approach (without the gedcom name), and it works here also :). Gee, I truly thought I had tried that variant already before...
Best regards,
.brum