View Issue Details

This bug affects 1 person(s).
IDProjectCategoryView StatusLast Update
03660Bug reportsSurvey participants (Tokens)public2009-09-15 12:30
Reporteruser1692Assigned Toc_schmitz  
Status closedResolutionfixed 
Product Version1.85+ 
Fixed in Version1.85+ 
Summary03660: Token import accepts invalid characters in the token value

When importing a token using a .csv-file invalid characters (for example a dash "-") can be inserted into the token value. This is usually filtered when using the web interface, so entering the token value "ab-cd" in the form will result in the token value "abcd" stored in the tables.

In any invitation and reminder emails the incorrect token value (with dashes) will be sent, but when the user clicks on the link or inputs that token, the dashes are filtered away and LimeSurvey cannot find the token without the dashes in the token table (where it contains dashes).

Interestingly, it sometimes shows the survey with an error message since it couldn't return token information from that token, instead of the error message that this is an invalid or used token. See the attached screenshot.

The token import through csv should probably filter the input just as if one had entered it through the web form.

As a side thought, how does LSRC handle when you "push" tokens into a survey? Does it filter the input too?

Another side note, does the manual specify what characters are valid as in the token code? I couldn't find anything at a quick glance.

Additional Information

In the screenshot the text in the bottom should be "Hej {FIRSTNAME}!" but since no token information was returned it became "Hej !"

TagsNo tags attached.
Attached Files
screenshot.png (49,290 bytes)   
screenshot.png (49,290 bytes)   
Bug heat4
Complete LimeSurvey version number (& build)7561
I will donate to the project if issue is resolved
Database type & versionPostgreSQL 8.3.5
Server OS (if known)Mac OS X 10.4
Webserver software & version (if known)Apache/1.3.41
PHP VersionPHP/5.2.4

Users monitoring this issue

There are no users monitoring this issue.




2009-09-10 00:57

administrator   ~09488

The token should consist only of numbers and letters. I will fix the import and update docs accordingly.


2009-09-10 08:38


Last edited: 2009-09-10 08:41

No other characters at all? Now I use an underscore to separate the first part of the token which is an internal ID from our other database so that it is easier to pair up responses and respondents, from the second part of the token which is a random ID that I generate.

It would be really handy for us if some character other than just numbers or letters are allowed, that is why I tried the dash in the first place. Underscores are not as good as dashes since link underlining in HTML makes them less visible, dash would be preferable for readability.


2009-09-10 08:59


Last edited: 2009-09-10 09:00

A clarification to why we need to be able to pair up responses/respondents, there are two cases where this is interesting for us.

First, all the respondents come from a selection from another database that is exported to a CSV. When an invitation email bounces that database must be updated and since you get the original email back when it bounces it is easy to look at the token in the letter and see what record in our database that should be updated. This CAN be solved by me exporting the unique id (that I use for the first part of the token) to an attribute field which I could then use in the invitation email somewhere.

But the other case is more troublesome. We often use LimeSurvey, not for surveys, but information gathering due to the extremely handy response tracking of the token system. Each year we hold a convention and the participants use LimeSurvey to tell us what seminars they want to attend to. My collagues that organize the convention can easily see using the statistics the participation on the different seminars. BUT another colleague sometimes need to enter those choices back into our database and up until now it has been easiest to make her the adminstrator and turn on detailed email notification. Then she get an email where the responses AND the token code (which include the id for the person). This could be handled if the detailed email notification for non-anonymous surveys included the token fields for the respondent (including extra attribute fields).

I would like this last solution, but that is not mutually exclusive with allowing certain non-alphanumeric characters in the token code (those that do not interfere with URLs, that is no slashes, ampersands, questionmarks, equal signs etc).



2009-09-10 11:18

administrator   ~09491

Underscores and hyphens will be allowed, too.

Issue History

Date Modified Username Field Change
2009-09-07 14:41 user1692 New Issue
2009-09-07 14:41 user1692 Status new => assigned
2009-09-07 14:41 user1692 Assigned To => user372
2009-09-07 14:41 user1692 File Added: screenshot.png
2009-09-07 14:41 user1692 Build Number => 7561
2009-09-07 14:41 user1692 Database & DB-Version => PostgreSQL 8.3.5
2009-09-07 14:41 user1692 Operating System (Server) => Mac OS X 10.4
2009-09-07 14:41 user1692 Webserver => Apache/1.3.41
2009-09-07 14:41 user1692 PHP Version => PHP/5.2.4
2009-09-07 15:02 Mazi Assigned To user372 => c_schmitz
2009-09-10 00:57 c_schmitz Note Added: 09488
2009-09-10 08:38 user1692 Note Added: 09489
2009-09-10 08:41 user1692 Note Edited: 09489
2009-09-10 08:59 user1692 Note Added: 09490
2009-09-10 09:00 user1692 Note Edited: 09490
2009-09-10 11:18 c_schmitz Note Added: 09491
2009-09-10 11:18 c_schmitz Status assigned => resolved
2009-09-10 11:18 c_schmitz Fixed in Version => 1.85+
2009-09-10 11:18 c_schmitz Resolution open => fixed
2009-09-15 12:30 c_schmitz Status resolved => closed
2016-12-08 10:39 c_schmitz Category Tokens => Survey participants (Tokens)