Check out the LimeSurvey source code on GitHub!
Welcome, Guest
Username: Password:

TOPIC: Your feedback: Plugins for LimeSurvey 2.05

Your feedback: Plugins for LimeSurvey 2.05 3 years 7 months ago #94740

  • trougakoss
  • trougakoss's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 1
  • Karma: 0
We are very excited to hear about the new plans for the plugin API.
There are many ideas that come in mind, but we would like to make a comment on the proposed encryption of the results of a survey (by tfj)

afterSurveySubmitted: encrypted functionnality (tfj)
questionPlugin: directly encrypted functionnality (tfj)

It seems quite useful and especially for a number of limesurvey implementations, where sensitive information might be stored.
Bearing in mind that the limesurvey application can be used as a voting system, we would like to propose the multiple (serial) key encryption of the responses, than just a single key encryption.
That would ensure the maximum security of the results and make the decryption proccess possible only when all involved parties can provide their private keys.

Thank you very much

Spiros Trougakos
NKUA (National Kapodistrian Univeristy of Athens)
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 5 months ago #96895

  • actxcellence
  • actxcellence's Avatar
  • Offline
  • Premium Lime
  • Posts: 42
  • Thank you received: 7
  • Karma: 0
In a number of project, customers asked me to use the multi-language email option for other e-Mail during the survey open period.

to excuse about some minor glitch in the invitation,
to remind and say thank you to all without filtering the participants who already answered

this is not a hook thing, but an idea for a e-mail plugin:

Send email to all tokens with this filter (filter in any column of the token table)
Schon die Bedienungsanleitung von LimeSurvey angeschaut?
Bedienungsanleitung (DE) | Tricks, um mehr Antworten auf Fragen im Forum zu erhalten
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 4 months ago #98250

  • jlwood
  • jlwood's Avatar
Has there been any movement on the idea of an encrypted field type? We're implementing Limesurvey in a University setting and this would solve a number of IRB headaches. I'm a mediocre php programmer but willing to try my hand at this as time allows.
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #99860

  • sammousa
  • sammousa's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 10
  • Thank you received: 3
  • Karma: 2
Hey guys,

Thanks for the ideas on encryption. Below I'll try to go into some concerns on encrypting data.
When applying encryption there are several attack surfaces that need to be considered:
- Database layer
- Application layer

When using symmetric encryption, encrypting data in the database only protects us from attacks on the database layer. Any attack gaining access to Limesurvey will also gain access to the key(s) used.

When using asymmetrical encryption we are able to make data secure from being read by the application itself, thus rendering any attacks on the application layer useless.

Since the database layer can, in most cases, be protected by simply denying all outside access I feel (symmetrically) encrypting the data inside the database is not the most efficient way to increase data security.

That said, applying some kind of asymmetrical encryption is definitely an interesting idea. It does have some downsides though:
- Limesurvey will not have access to the stored data, breaking any kind of dynamic texts and conditions for surveys that are not finished in one go. (ie. that have their data written and read from the database between start and finish, for example when resuming from a token link).
- If we don't want the data to be stored (unencrypted) in memory a lot of changes are required to the core to ensure that data is encrypted as soon as possible after receiving it.

In 2.10 we will introduce question plugins, these are question plugins will allow third party developers to create question types and will definitely allow you to add both symmetrical and asymmetrical encryption to individual questions.

For 2.05 there are several features that might aid you in developing a solution that is secure enough (in security nothing is ever really secure, it is secure enough or not secure enough).

- use the afterSurveyCompleted event to get the data, encrypt it and store / send it. When using the default plugin getters and setters this won't be the most efficient approach when exporting big data sets later, but it will work and be secure.
- if you want us to we can add a function to the plugin api to allow you to delete responses, your plugin could then delete the response after having encrypted and stored it.

Thanks again for the feedback, and keep the suggestions coming!

(disclaimer: While being part of the team, the opinions stated are my own and don't necessarily reflect the opinion of the Limesurvey development team as a whole.)
Last Edit: 3 years 2 months ago by sammousa.
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 20 hours ago #102331

  • Spydre13
  • Spydre13's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 7
  • Karma: 0

I just came across this post from a while back about custom hooks. I am trying to integrate limesurvey with a medical application, and I'm very interested in your #3 and #4 hooks. We had been using the newtoken.php for limesurvey <2.0 but it's not as secure as we would like. Are these hooks something you could share with myself and the community, or is it something you need to keep private?

I'm specifically trying to pass users into a survey in a secure method, without the possibility of users viewing their browser history and getting back into a previous survey. Also some data in the survey is sensitive, so it can't be visible on the URL in the browser history.

Any insight from you or anyone else on this site would be greatly appreciated.

helper wrote:
From my perspective (learning hospital/university), the objectivity of an API would be to provide hooks to other API's (for example, advanced web services). These could include interfaces with print services and/or electronic medical records (like Epic).

My current homegrown hooks:
  1. Output report customization for PDF/print and BLOB preparation for mainframe DB2.
  2. Output report writes to mainframe DB2
  3. Survey logon based on a medical record number and year of birth instead of token, username/password.
  4. Automatic token generation when a patient logs on.
  5. Appointment lookup (via web service to our appointment systems)
  6. Token population from patient registry flags (for example, diabetes, hypertension, etc.)
The administrator has disabled public write access.
Time to create page: 0.263 seconds
Imprint                   Privacy policy         General Terms & Conditions         Revocation information and revocation form