Problem with resetting password from email message

[OldNick]

I'm sorry - my ineptness is testing your script to the limit!

The good news is I've signed up to a host that offers as part of the deal a full security package (firewall, ddos etc) and varnish caching I can control as I want.

Now the bad news

I tried restoring from a backup (to get content and settings from the old install) and managed to shut myself out of the site admin again. I tried to reset the password by sending myself an email - which worked (although I didn't quite understand, at first that there was a link I had to follow - question of layout, if I know which file it is I can have a look). However, when I tried to follow the link .../npg/admin-tabs/users.htm?ticket=$ref&user=... I'm afraid I got error messages WARNING: "pack(): Type H: illegal hex digit $" in .../public_html/npgCore/lib-auth.php on line 773

WARNING: "pack(): Type H: illegal hex digit r" in ../public_html/npgCore/lib-auth.php on line 773

WARNING: "Cannot modify header information - headers already sent by (output started at .../public_html/npgCore/functions-basic.php:117)" in.../public_html/npgCore/admin-functions.php on line 5122

WARNING: "Cannot modify header information - headers already sent by (output started at .../public_html/npgCore/functions-basic.php:117)".../public_html/npgCore/admin-functions.php on line 5123

WARNING: "Cannot modify header information - headers already sent by (output started at .../public_html/npgCore/functions-basic.php:117)" in .../public_html/npgCore/admin-functions.php on line 5124

needless to say I didn't get to where I should be going.

I think I made a mess of the restore - there were two boxes I didn't know what to do "Admin to objects" and "Admins" (or was it users) - the first I ticked and the second I didn't... I think I'll wipe the database and start again

[sbillard]

This is indeed disturbing. Mostly since at least in my copy of the software line 773 of lib-auth.php does not have any "pack()" function call. For me it reads: 'VIEW_SEARCH_RIGHTS' => array('value' => pow(2, 6), 'name' => gettext('View search'), 'set' => gettext('Gallery'), 'display' => true, 'hint' => gettext('Users with this right may view search pages even if password protected.')),

The other way of resetting a password is to delete the admin table and re-run setup. That should have happened when you did not tick the "administrators" table the "admin_to_object" table contains the "ownership" data. Generally they should be both checked or unchecked.

I will do a little more research and get back to you on this.

[OldNick]

Here's the debug log - I tried again today... this time not checking both tables Still got locked out (don't know what I'm doing wrong - or more to the point, don't know what I'm doing...) - it's got more data than the raw error message.

I've changed my user name in moving servers what will happen to the user on the albums etc?

I'll go drop the admin table and see what happens.

[OldNick]

Got back in! And removed IP Blocker... which removes one possible source of unhappiness.

[sbillard]

Most likely the album users will "vanish". The admin_to_object table associates albums to users by the id's of each. I would assume that changing your user name would create a new entry with new id. It the old user is still there it would still be associated with the albums.

[OldNick]

I think the old user name is still the owner, but as my new one is super admin, I don't think it'll make any difference. Anyway it works! And a hell of a sight faster too (the new server)! If you've downloaded the debug log I'll remove it from the post - I didn't edit out the site details

[sbillard]

I've downloaded and removed the log. It does tell me "what" is wrong, but it also makes no sense. What version of nPG are you running? The line numbers in the debug log are way off what is in the current release. Anyway, the "problem" is that the ticket generated had a ticket value of "$ref" which is not correct, it should be a hex number. This was once a bug, but corrected last January.

So most likely you are pretty far behind on the version of you installation. I suggest you upgrade. (Of course that is how we got here in the first place, isn't it....)

You can use the album page bulk actions to change the owner if you wish.

[OldNick]

I'm not in the latest version... I think it's .40 I decided to go from source and I think it's the latest available.

I'll update next time I'm in admin.

I think the problems before were less to do with upgrading than with a botched server change.

[OldNick]

Sorry, but I'm reopening this - rather than starting a new one.

I updated and then found myself locked out... I don't know what happens in the upgrade process, but my password stops working (I use alphanumeric and punctuation characters).

I can't test the password reset (didn't expect to have to) as the captcha is unreadable - it's already tiny, but now the text is "below the fold" - you can see the top of four characters and that's all - so if it's five characters, you're definitely cooked, because they're offset to the right...

[sbillard]

I presume this it the netPhotoGraphics captcha? What captcha font did you select and at what font size? Can you attach a screen shot?

You can use phpMyAdmin and change the npg_captcha_font to * which will give you a random selection of fonts. Then you can refresh until you get a usable one.

As for why the password stops working, I have no idea. Maybe you can detail your upgrade process for me?

[OldNick]

I didn't select anything - just left the defaults, or rather I've never looked at it at all!

Upgrade process was just clicking on the button saying "upgrade to version xxx" - then afterwards I hid the setup files which is a bore. It's done it to me before, but in local installs. I've looked at the database and my user and password are still there. I didn't look at admin to objects though, nor have I looked at the security log. I'll have a look at those two and report back.

[sbillard]

Sorry about your having to hide the setup files. Mostly that is because you might be updating clone installs. I suppose that it might be possible to keep track of the installs and auto protect them but that would be prone to failure (if you close the browser, for instance) leaving the scripts unprotected.

[OldNick]

Here's the security log - please delete from here after download. The table 'Admin to Object' is empty.

When I get in again, I'll look at the Captcha config...

[sbillard]

Got the log. Is that string it shows on the failed logon your password?

[OldNick]

Yes. I use a password app...

[sbillard]

I presume you haven't changed it during this log period? So it must work for a bit then fail. The other thing that seems strange is the install records. They seem to show the following sequence:

start install for 2.00.04.00 complete install for 2.00.04.00 start install for 2.00.04.00 complete install for 2.00.04.10 [sic] start install for 2.00.04.10 complete install for 2.00.04.10

[OldNick]

That is weird - I'm not sure what I did. Something happened during the upgrade process and I did it again...

Just re-installed. Created my user and I'm locked out again. Admin_to_object is still empty.

[OldNick]

And the same thing has happened again - this time I dropped the tables rather than empty them.

[sbillard]

Have you tried running the site a bit without doing a database restore? Just create your master user and see if that "takes". We need to narrow down the things that might be impacting this issue.

[OldNick]

I'll do it tomorrow - as we're locked down here, I've got all the time in the world...

I'll go with the latest version maybe (could there be a conflict through the upgrade?) and a fresh database. Could there be something weird in the database backup - it was from a different server altogether - and I didn't have the problem on the last server (until they moved things)

There was something that flashed up that I'm not in the latest version of MySql - 5.5, I think - but it's nigh impossible to find the latest of anything. Do have PHP 7.4 though.

[sbillard]

I would not think the MySql version would be a problem

[OldNick]

I had a thought, waking up, which could have a bearing on the problem, on the old site I'd turned off using EXIF data and, as a result, I remember the database being modified.

I've got a PHPmyadmin backup of the database as well - I'm going to try importing that and dropping the two admin tables...

[OldNick]

Sorry about the delay - a small matter of COVID... I did a virgin install - all tables dropped in the d-base and new upload of extract.php - and it happened again shut out, immediately after creating my user, only this time the e-mail to re-initialise the password didn't work either. Here is the security log and an export of the only two tables that could have changed - admins and admin to object. (as usual delete here when downloaded) - I left albums up there, which are on the dBase but untouched.

[logs deleted after fetching them]

In the security log it says something about a problem with a cookie...

[sbillard]

So from the security log it would appear that you tried logging in with two different passwords? I don't think the cookie failure is relevant. That would happen normally if you change passwords (or add a user) as the existing cookie would no longer be valid.

By "the emails to re-initialize" did not work what exactly happened. Did you get to the admin page to change the password but the change failed or did the ticket fail so you did not get to the reset page.

I would suggest you try using a password that contains only ASCII characters. There may be some server/browser handling of the non-ASCII characters such that they are not being passed correctly.

[OldNick]

I certainly don't think I tried logging in with different passwords - I used the password manager to set up my user and then to log in. I've reset the password to vanilla alphanumeric, so we'll see what happens.

The reset didn't happen because I didn't get the email...

Maybe I'll drop the albums so there's absolutely nothing there.

[OldNick]

Just tried - twice - triple checked everything - and still locked out...

Here's the log - it would seem to be the cookie that fails - I don't pretend to understand what is supposed to be happening.

{log deleted]

[sbillard]

The sequence of events is important. The login cookie failure came after the successful add user. There won't be a logon cookie for the new user until he has successfully logged in and that has not happened. Instead the actual login is failing. At least this time the password had remained constant, but not at all like the ones from the previous log. No non-ascii characters.

The way the software works is that when you create a user the password you supply is encrypted based on the hash algorithm that has been specified in the security options. When you log in, the password you supply is checked against the stored hashed password. Please check what algorithm has been selected. At least based on the authorization cookie shown in the log it is not one of the more modern ones. (Maybe in this chain somewhere you have told me your PHP level, but I don't see it at the moment, so please repeat.)

The other thing that might help is if you enable the debug plugin and set its option to log admin saves and login attempts. Perhaps there will be better detail of what is happening logged to the debug log then.

[OldNick]

PHP : 7.3.15 MySQL : 5.5.5 My problem is I don't get far enough to enable anything or check anything. The only page I've got is create user, no other tabs available. So I create the user and I'm immediately kicked out, as I save the password. There is something on the server called ModSecurity which is automatically enabled, could that be doing something?

...happened again - it really is as I click the create user button the login page loads and doesn't recognise either user name or password. If I then go to /npg/admin I get user / password error and the invite to redo my password... I don't remember earlier versions doing this (as I think about it) I seem to remember creating the user and then having access to other admin pages - not being booted.

Looking in the database I found "strong hash" value "3" The only thing I can think of is installing then, before I go into admin after installing, I go into phpMyAdmin and change the fields to enable debug logging - but you'll have to tell me which fields and what values to set. (or could I do it through config.php)

[sbillard]

Sounds like something went wrong with storing the new password. I presume there is nothing in your debug log. Have you looked at the cPanel PHP error log? I doubt that ModSecurity is involved, but if it can be disabled we might want to try that.

I think your proposal to install then make direct edits before trying to set up the admin is the right way to go forward.

For the login debugging you can edit the version.php file in npgCore. change the DEFINE since that is what the debug plugin would have done anyway.

define('NETPHOTOGRAPHICS_VERSION', '2.00.04.11.06-DEBUG_DISPLAY‑ERRORS_LOGIN_TESTING');

(Leave the version number as it was or setup will want to run.)

For the 'strong hash" set the value to "1000" which will select the "default" algorithm. With PHP 7 this invokes PHP based password verification which will at least change things.

[OldNick]

I'll start again tomorrow - I supposed to be convalescing - COVID is a very strange and alarming experience, even the mild dose (and I'm just hoping it doesn't come back for another try)

[sbillard]

I am sorry for your illness. Get healthy and stay healthy. We have been hunkering in place for a bit now.I got a cold which initially scared me, but it stayed upper respiratory and is almost all cleared up now. Do you know how you were exposed?

[OldNick]

Not at all - the figures about number of cases are rubbish. They've only tested people admitted to hospital. Even though I've talked to a doctor and he's pretty sure I've got it, my case will not be in the statistics. A couple near me have just come out of it after 10 days so it probably means it's been in the area at least 3 weeks. The lack of preparedness and indiscipline has been depressingly eye opening. Part of the problem I think is that the UK and France have dumped all their manufacture in China and the third world, so they couldn't get supplies. Germany and Scandinavian countries who still have a home manufacturing economy seem to be better prepared and faring differently. And, in France, there's only 70 labs with the accreditation to analyse the tests (for 60 million people).

[OldNick]

We have lift off! At least I think so.

I did the two steps you suggested and added a third - basically, having edited version.php, I thought while I'm here why not have a look at config.php to look at the database details (mainly because I'd fluffed the table prefix, putting the underscore in the wrong place) - and I noticed an entry about http protocol which I changed to https.

I've had a problem with that from the beginning - the server automatically set's up Let's Encrypt certificates, but despite using the .htaccess snippet to force https (which I had to use on the last server) it was still coming through as http. Now I have a working site and https! It seems that to get https on this server the script had to install as https which may be the source of the original problem.

I don't know if there's a way of testing for https - on this server the certificates are stored in /ssl/ - outside /public_html - this web host is far more sophisticated than the last one. I'm paying considerably more, but the other one started cheap and the everything else was extra - I'm not sure that I wouldn't be paying more if I'd gone for the addons necessary to get what I have here.

[sbillard]

Good that things are working now.

The scripts do test to see if they were accessed vi https, and so will respond accordingly. There is a cookie stored named "ssl_state" that will be set to indicate the site should be running https. But we do not force https unless you set that config item. Maybe it is no longer true, but historically a servers did not support ssl unless you bought a certificate, so would not run at all if you tried https. I know the web host I use was that way up until about a year or two ago.

If your site was switching between http and https that might explain things. If you logged in via https and then visited via http the logon cookie would not be accessible to the server, so the script would not know you were logged in.

The US is probably in the same situation as you. No real knowledge of how far the disease has spread. Not enough tests, supplies, etc. To add to that there is too much of the country that seems to have the attitude that this is someone else's problem. I am in California, at least our officials are up front about the deficiencies and doing what they can (which is limited) to resolve them. In the meantime our "president" wants to open the country up for Easter services!

[OldNick]

I saw the cookie - I was taking details in case they would help. It flagged as false. I will try and find out from support what is going on - all the time it's been showing as not http in the browser, and forcing the install into https has given me the little padlock with "certified by Let's Encrypt". It seems that perhaps it was behaving as https but not providing the right information to the browser. The directory structure on the server is a little different from what I've seen before - The server root is home/my-account-name and I could have certificates for the whole thing, not just /public_html - but they do say they'd prefer you not to, which perhaps is the root of the problem. My site is, in fact, a sub-domain of my account. One of the instances for which I could have had certificates is my-site.my-account

I'm going to have work out what to say in French...

Anyway, It seems to work - thanks very much for all your time. I may have other questions, but easier ones than this.

Looking at the news here, apart from states like your own, doing their best, the outlook is very dark. The incompetence and denial at federal level is horrifying. It seems to be a trait with these authoritarian "leaders" that they deny anything is happening. The first cases in France came from Egypt when the Egyptians said there were none, and they've just thrown out the last foreign journalist for citing a report putting their figures in doubt. It's extraordinary how ego comes before humanity and good sense with these people.

[sbillard]

The config.sys change should stabilize things. It forces the software to use https and causes a redirection if the incoming link was http.

I have a soft spot for France. My family is from there (I'm 4th generation US.) My dad spoke French at home. Unfortunately he did not continue that for my youth, so my French is faltering. We came over in trying times as well. This plaque is on the wall of the school in St. Leon (near Vichy) where the family is from.

[OldNick]

That's a bit of history I know nothing about! I'll have to do some reading.

In many ways France still hasn't sorted itself out - I'm in the West and there are still communes here who do not have a state primary school (école public) 140 years after the law requiring it was passed... Republicanism is at a low ebb at the moment - the 5th republic is one in name only.

If you can get your hands on it, Woody Allen got published a subtitled version of a two part documentary called "Le chagrin et la pitié" - The Sorrow and the Pity. It's a extraordinary piece of work about France under Pétain and the occupation and well worth seeing.

[sbillard]

Well, doesn't look like it is available in a format I can use. I'll keep looking, though.

[sbillard]

I have been able to reproduce this issue, I think. At least something that has the same behavior. I am testing the fix so it should be available in a day or so.

[OldNick]

Well, it's good to know that all the trouble I've caused hasn't been wasted ! I'll have to find out more to explain exactly what's been happening.

I don't know if you do torrents, but there is one that still works for Le Chagrin et La Pité - .avi format - otherwise I can try and put it in the cloud.

[sbillard]

What I found was a bug in handling the php password hash algorithm selection. What was supposed to happen was that if a user's password hash was made with a deprecated hashing algorithm he would be forced to re-login which would update the stored hash algorithm. But under some (I'm still not sure what) circumstances,) even though the hashing was done with the new algorithm the software thought it needed updating. In your case the update to _stronghash int he database is probably what "fixed" the issue. But I would not do any clean installs until the fix is released.

I haven't used torrents in eons. Don't even remember how it works.

[OldNick]

Try this (url) (Probably better wipe it after use) there's a bit in one of the episodes where it goes a bit funny, but it rights itself - at least using VLC.

As I think about, I remember during setup - fresh version there was a message saying I was using an outdated encryption cipher...

[sbillard]

I've downloaded the file. Thanks. I will look at it a bit later.