I have been updating for years by deleting everything but uploads, unzipping the newest stable release, and then unzipping an archive with my config.php and a couple of template files. I just set up a new survey which ran fine, and saved the responses, but then died on a 500 error page with a message that the encryption keys had changed and the data was lost.

Turns out there's an application/config/security.php file created when encryption is first used (which hasn't ever happened that I know of) that stores the keys. Due to my updating method (which is still what's suggested in the manual, by the way) I have apparently been deleting this file every month when I upgrade, and it's been regenerating. However, this is now causing the 500 error at the end of my surveys.

I've created several new ones, all with the same result. It doesn't seem to matter that no fields are encrypted, and whether the info is anonymized or not, and so on. One long text question, no storage about the participant (IP, timings, etc) and the same error.

I'm happy to save the current security.php and just make that part of what I restore, but I would need to be able to fix whatever causing the system to think I care about encryption.

Just to elaborate, NO questions have encryption set. I've found LSSodium.php which generated the error I'm seeing, and it should only be used if encryption is in place. It isn't, or at least not in any option I can see (question attributes, and I'm using an open survey, so no participants table).

Right. I've managed to just disable the sodium library, as well as the exception thrown within it. This seems to have cleared up the issue, though obviously in a temporary and probably not advisable way.

I don't think this is probably going to help much, but the edited file is attached. I see where the function to check for a valid decryption is, but not what it's checking against. Is there a field in the DB that I can delete (maybe along with security.php) and just take this back to scratch, and then save security.php during future updates?

Hi,
the manual mentions specifically that this file needs to be preserved. I have updated ti to make the statement more prominent.
Anyway, your error on submission stems from the fact that the SMTP password is also saved encrypted and you probably send email at the end of the survey.
If you save your SMTP password again, the error should go away.

I think it's better if we move encryption key in config.php

I make a mantgis about this.

First of all, this is the second time I've actually posted here, and you folks are right on the ball. Very impressive.

@c_schmitz : I see that the manual does say that now, but of course it didn't when I last read it. I guess it'd be an idea to check it again, especially after major version changes. I didn't think of the SMTP password, but it might be worth mentioning that no emails were being sent. It's an open survey, so no participant email address, and neither of the admin notifications is turned on. Anyhow, I'll restore the original LSSodium.php and try that for a non-kludgy fix.


@DenisChenu : That might be a good idea, but if you're just modifying it silently behind the scenes it wouldn't have helped me in this case. I basically have a zip of the stuff I need to restore, and I just delete everything except uploads, unzip the new version, and then unzip my stuff and overwrite where needed (templates, etc). Maybe I need to revisit this, but I have 5 installs going, so plucking individual files from sub-sub-sub folders (in the case of the templates) is pretty annoying. Now that I know to include security.php with my "stuff" to restore, I should be fine again, at least until the next change along these lines.

Anyhow, once again, thanks for being so quick with the solution.

Note: The hint regarding security.php was in the manual since February 17th.

I think you may be overestimating how often people read the manual when things appear to be fine. Much like terms of service and update changelogs. Unfortunate, but there it is.

There are another issue with config.php.

A way to setup with an existing DB is to delete config.php and install again ...

Arg ... complex situation ....

Maybe
1. $_ENV (Environment variables)
2. config.php config array if exist
3. security.php

Then : user have choice ?

I think you may be overestimating how often people read the manual when things appear to be fine. Much like terms of service and update changelogs. Unfortunate, but there it is.

I agree with you, people will not consult the manual all the time, especially as it hasn't been updated for quite while for installation, if I recall right.

But I don't think that this was what Carsten wanted to say. I guess it was more to keep it documented since when this applied, for people that come to this post in the future. I might be wrong though.

That makes sense. I'm desperately looking for a way not to feel dumb.

Ideally, this could be in config.php, and that file could sit in the root. It's a pain having to not delete a file (or files) buried in the hierarchy. But that might be asking too much, as well as obviously messing with the well-organized approach.

I think Denis is thinking about a solution already.