#2952 "And" in a place name causes issues

[Douglas Terry]

I have been aligning all my place naming with standards and now find that any that include the word "and" in them cause multiple issues.
Issue 1: Any selecting of a place name (such as "Dundas and Glengarry United Counties", "Leeds and Grenville United Counties", "Newfoundland and Labrador", …) causes an immediate 403 error and the IP address to be put in the timeban list. This happens from within most dialogs and lists, but not within the "Edit geographic place locations" module.
<image4>
If it helps, the selection of one of the place choices below results in the following URL with the issue: https://mysite/phpgedview/placelist.php?action=show&parent[0]=Canada&parent[1]=Ontario&parent[2]=Dundas%20and%20Glengarry%20United%20Counties&level=3 </image4>

Issue 2: In the admin "Perform batch updates/edits on your GEDCOM", choose search and replace, then in the "Search text/pattern:" field put in any text that has "and" in it then move off that field will cause an immediate 403 error and the IP address to be put in the timeban list. This is caused under all search methods types.
The only way around it that I have found is tricking it by doing several steps that include only part of the word "and" then following with a second replace with the rest of the word. For example pass 1 would only be for "Dundas an" while a second pass with "d Glengarry United Counties".

Issue 3: In the admin "Perform batch updates/edits on your GEDCOM", choose search and replace, then in the "Search text/pattern:" field put in any text that has "&" and the whole field automatically erases. For example through the person details dialog box I originally had filled in "Leeds & Grenville" in for a place, but then found I couldn't use the admin search and replace feature to fix it because the "&" in the phrase automatically caused the field to be erased when it was moved off of

[Gerry Kroll]

This bug was discovered some time ago, and was fixed in the SVN. Please update your PhpGedView installation to the latest-and-greatest "SVN" version. Try ALL of your reported problems with that version.

Download the SVN snapshot from here :
https://sourceforge.net/p/phpgedview/svn/HEAD/tarball?path=

The actual problem is with the code that detects SQL injection. "and" is an SQL keyword. There are several others, such as "union" that will cause similar problems.

[Douglas Terry]

Thanks Gerry. I am running SVN 7311 and hadn't seen any updates in the history since so that is why I hadn't just updated. I will update first thing in the morning and let you know if I find any related issues.

[Gerry Kroll]

If you are on SVN 7311, you won't see much change. There were NO updates from then until SVN 7320 that address this problem.

[Gerry Kroll]

Edit line 298 of /includes/session_spider.php , to remove
and|
That should fix the sensitivity of the program to the word "and" in incoming requests.

I'll update the SVN accordingly.

[Gerry Kroll]

SVN 7321 incorporates the fix.

The word "and" in incoming requests no longer triggers the "SQL injection" error.

[Douglas Terry]

Last night I copied the phpgedview-svn-r7320-trunk files over my existing directories and this morning after restarting the server it still won't come up indicating "Site is currently unavailable". Was there something else that changed between 7311 and 7320 I need to look into to bring my site back up?
I just generated a 7321 snapshot and installed that but still the site indicates it is unavailable.

I reverted to 7311 and the site suddenly is available, so there is clearly something that changed between 7311 and 7320/21 that causes the site to be unavailable.

[Gerry Kroll]

The "Site is currently unavailable" error comes from the install.php script.

The error occurs when the config.php file says that the site is configured, but the database connection credentials don't work. In other words, the error means that the program can't connect to the database.

You can edit the existing config.php file to verify the database connection credentials, or you can change the second-last line in this file to
$CONFIGURED = false;
so that when you launch PhpGedView, you're given the opportunity to re-enter the database credentials.

You can also delete the existing config.php file (or re-name it) so that the install.php script copies the config.dist file to create a new config.php file.

[Douglas Terry]

I tried copying over the config.dist and manually updated all the fields, with no luck.
I then reverted to 7311 and the site suddenly is available, so there is clearly something that changed between 7311 and 7320/21 that causes the site to be unavailable.

[Gerry Kroll]

Let's take this off-line.

E-mail me directly (not through SourceForge) : gkroll (at) keldine (dot) ca

I'll have to investigate this by logging in to your site and checking things out. This includes FTP access and Admin access to the PhpGedView site.

When you upgrade to SVN 7321 from an earlier version such as 7311, all you need to do is to copy the PhpGedView files to replace what's already on your site. If you choose to do a complete replacement, you need to preserve the config.php file and the /index and /media directories.

[Gerry Kroll]

This problem was caused by a recent change to the way the install.php script works, combined with the user having chosen "root" as the database userid. When PhpGedView sees that the database userid is "root", it assumes that the database connection credentials have not been configured properly. It will refuse to accept "root" as a valid database userid.

In general, you should avoid using "root" as a valid userid for anything, since that's a favourite method for hackers to gain access to the system.