It seems that in 502 when I save making changes in Globals->Administration I get a white screen:
This is the thing. When I use an older version of the database I don’t get this issue. Could this be related to one of the new patches?
When I look at the Apache error log I get the following:
hi @growlingflea, is there a permissions issue in the logs_and_misc subdir of the documents folder under sites?
That directory is owned by www-data.
I’m currently working on an upgrade of a custom system. When I use an older copy of the database from a few months ago, it works fine. But when I use the most recent copy of the 501 and upgrade it to 502, I get that issue. I’m thinking that maybe it has to do with a new version of the upgrade script or patch.
Ive tracked the issue to this line:
but the code that throws this error is in the Utils folder.
I’m not sure where the csrf token is being generated. I wonder if maybe there is an issue with the database but when I did a tail of the sql dump, it produced the expected output.
After doing more extensive troubleshooting I found where the error is happening.
in Edit Globals, the issue starts happening when $grpname = “Notifications” and the $fldtype is a password.
Then when it gets to this line of code and it goes into the encryptStandard method, it breaks
I’m still doing more research into why this is happening with one database and not the other.
It looks like the old database doesn’t have passwords in the password fields in the Globals area.
I went in and removed the passwords (SMTP, WMT, and Whemo) and now it seems to work fine.
When I enter a new password, it throws the error and it all seems to come from here:
The only argument being passed to the method is the password.
hi @growlingflea ,
Quick key background:
logs_and_misc subdir of the documents), which is used to encrypt data that is stored in the database (this is the keyset that is used to encrypt password/sensitive data in globals). The kicker to this mechanism is that we actually encrypt this keyset on the drive with the keyset in the database. Thus if you try to take a database from another instance (different keyset in keys table), then the encryption/decryption to/from the database will break down (since it it no longer compatible with the key stored on the drive(i.e. it can’t be unencrypted). I am guessing this type of problem is what is causing your issue. A way to test this would be to remove the keys in logs_and_misc subdir of the documents (make sure you keep that key around though in case this does not work) and then a new key will be created that is compatible with the keyset in the database. So, the save in globals should now work. Before you get in habit of doing this, do realize, that by removing the prior key from the drive means you would never be able to unencrypt the encrypted stuff stored in database (database globals and the log stuff if you have log encryption turned on).So I think I understand what is going on. I’ll give some background.
I have a highly customized version of 501 for one of my customers. In September I created a new instance of 502 (on my development server), brought in the code, and used the upgrade script. Everything worked fine.
A few weeks later I moved a more recent snap-shop of the live database (501) and ran the upgrade script again so I could work with a more recent version of the database. I ran this database through the upgrade script and this is when I started having issues.
According to what you are saying, when I created the initial instance of 502 using the older snapshot, an encryption key was created using the older database. When I attempted to use a new version of the production database on my development server, it won’t save things to Globals because the keys are different.
Your advice is to remove the keys in logs_and_misc and this should solve my issue. Since I am only working with backups this should be fine.
My question is this: When I am doing development where I am consistently taking a 501 database of a custom system and I load it onto my 502 development system, are you saying that I should remove these keys every time?
hi @growlingflea ,
In your case, where it appears you are only moving the database and not the document store. After you take the 501 database into your 502 development system, I would then repopulate the keys table from your original 502 development system. This should then keep the key sets on the database and the document store in line.
-brady
Thank you so much. That makes all the sense now.
I’m having a very similar issue. Can’t insert data into the system.
ERROR: query failed: INSERT INTO keys (name, value) VALUES (?, ?)
Error: Duplicate entry ‘sixa’ for key ‘name’
I’ve tried deleting the two files in the /sites/default/documents/logs_and_misc/methods dir, but nothing.
Are you running the upgrade script?