500: Internal Server Error Argument 1 must be at least CRYPTO_SIGN_BYTES long

More
2 years 4 months ago #194454 by plafeber
I was learning about the CPDB and saw that this is a central table that was originally empty.
I decided to migrate the local participants from my first survey to the CPDB. I had already added one custom attribute "attribute_1" to document per participant what company they are from.
From then on, I was no longer able to enter the CPDB because of the message in the Subject of this topic. I guess there is an issue with moving local participants with custom attributes to the CPDB. I have not yet logged this as an technical issue because I don't know how. I have been a member for a week now.
I would like to start over with the Participants. It's not a long list to rekey. What is the best way to get rid of this issue?
A>> Remove tables "lime_participant_attribute" "lime_participant_attribute_names" "lime_participant_attribute_names_lang" and "lime_participant_attribute_values"?
B>> Download my survey structures, then reinstall Lime and upload again?
C>> Somehow removing the reference to this attribute 1 elsewhere so that the CPDB no longer hits this problem and I can start over creating custom attributes directly in the CPDB.

Update; I thougth to be smart and went directly to /limesurvey/index.php/admin/participants/sa/attributeControl. I told the system to remove my custom attribute, but the message stays the same.
The topic has been locked.
More
2 years 1 month ago #199882 by a786458
I encountered the same problem when trying to migrate local participants into the central participants database, no custom attributes involved though. So I don't think that these are part of the problem. I couldn't fix it for now.
The topic has been locked.
More
2 years 1 month ago #199891 by tpartner
If using the latest 3.x LTS or 4.x version, please file a bug report.

Cheers,
Tony Partner

Solutions, code and workarounds presented in these forums are given without any warranty, implied or otherwise.
The following user(s) said Thank You: cdorin
The topic has been locked.
More
1 year 11 months ago #202804 by ggna
I've just encountered the same problem : I tried to add to CPDB two participants from an existing survey, and immediately after was not able to access the CPDB because "Argument 1 must be at least CRYPTO_SIGN_BYTES long".

Having direct access to the MySQL database, I identified and looked into the table named lime_participants, and saw that all other participants had their own "firstname" and "lastname" encrypted, whereas these fields were plainly readable (unencrypted) for the two participants transferred from my survey.

I had them manually removed (via the MySQL commands:

delete from lime_participants where firstname="Aaron";
delete from lime_participants where firstname="Zack";

) and the system started working again (i.e. I could again access the CPDB from the website).

I conclude that the script which transfers participants from one survey to the CPDB does not pre-encrypt the required fields.

Best,

Giuseppe.
The following user(s) said Thank You: plafeber
The topic has been locked.
More
1 year 11 months ago - 1 year 11 months ago #202813 by DenisChenu

tpartner wrote: If using the latest 3.x LTS or 4.x version, please file a bug report.

community.limesurvey.org/bug-tracker/

Assistance on LimeSurvey forum and LimeSurvey core development are on my free time.
I'm not a LimeSurvey GmbH member, professional service on demand , plugin development .
I don't answer to private message.
Last edit: 1 year 11 months ago by DenisChenu.
The topic has been locked.
More
1 year 8 months ago #206340 by plafeber
That was it. It must have something to do with the encryption tool "Sodium". As no participant names had been encrypted in my table, I have first exported the rows then truncated the table. Now I can enter the table again.
The topic has been locked.
More
1 year 8 months ago #206357 by plafeber
I am now continuing working with the central participants table and the tables for the surveys. I have tried to add a central participant to a survey. It gives me a garbled participant. I know it is the encrypted value of the participant from the central table. It tells me that the survey participants table is not encrypted and the values are stored as is.
I have checked the survey participants table and indeed encryption is off. The solution is to, per survey, set the attributes all to being encrypted.
The topic has been locked.

Start now!

Just create your account and start using Limesurvey today.

Register now