In our company, we do online surveys. We recruit our survey participants in two ways: 1) our own pool of e-mails of people that have registered with us, and 2) online media that post our surveys in their content. The challenge with this is to have the ability to 1) send e-mails and 2) have an openly accessible link for the media to post. We solved this challenge by creating a token for a superuser with a very high number of "Uses left" (say, 10'000). We use this token in the link that we provide for the online media. For the e-mail participants, we use tokens the regular way.

Twice now already, one of the "superuser" tokens broke down. People trying to access a survey with this token get an error 500. All the other participants can access the survey normally.

One option to tackle this problem would be to have two surveys: an open one without tokens for the media, and one with tokens for our e-mail pool, but this creates extra effort to bring them both together.

What causes this issue? Is there a better way to tackle this? How can we avoid it in the future?

How about sending the online media folks to a PHP page that uses the API add_participants() method to create a new token and then redirect to the survey?

Here's a post with a PHP script that could be modified for your purposes - www.limesurvey.org/forum/can-i-do-this-w...-fly?start=15#158184

More on the API:
- www.limesurvey.org/manual/RemoteControl_2_API
- api.limesurvey.org/classes/remotecontrol_handle.html

I'd say it's a server configuration problem.

Thanks @tpartner for the hint – we'll definitely try this out.

For the sake of completeness: we contacted our web host about this the last time this occurred. Since we don't have a trained dedicated webmaster, we can't really trace what causes the error ourselves.

Here's their response (in German, with a quick English translation):

---

Ich habe bezüglich dieses Fehlers noch folgende Meldung im Error Log des Webservers gefunden, welche sich immer wieder zeigt.
(I have found the following notification in the error log of the web server regarding this error)

[Mon Jan 29 16:05:55.299148 2018] [core:error] [pid 94220:tid 34698968064]
[client 46.140.205.236:39438] AH00125: Request exceeded the limit of 10
subrequest nesting levels due to probable configuration error. Use
'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel
debug' to get a backtrace.

Ich vermute anhand dieser Meldung, dass bei der verwendeten Applikation Survey zu viele interne unteraufgaben "meist .htaccess redirects oder ähnlich" gemacht werden.
(I assume that the application Survey does too many subtasks, usually .htaccess redirects or similar)

Wenn ich im Verzeichnis …/web/CMS/survey und dessen Unterverzeichnissen nach der Steuerdatei .htaccess suche, wird diese von Survey wie es aussieht massiv verwendet, da in jedem Verzeichnis eine angelegt wird.
(When I search the directory …/web/CMS/survey and its subdirectories for the file .htaccess, it is massively being used by Survey, since it creates one in every directory)

Das Problem hierbei, in jeder dieser Dateien hat es Steuerbefehle wie die Webseite aufgelöst werden soll. Hierbei können wir unmöglich sagen, in welcher Datei genau der Fehler passiert. Hier müssten Sie oder Ihr Webmaster den Fehler ermitteln, oder allenfalls beim Hersteller der Applikation um Rat fragen, ob diese Regeln korrekt definiert sind. Meist gibt es in Applikationen auch ein erweitertes Error Reporting, damit Sie allenfalls eine genauere Fehlermeldung erhalten.
(In every one of these files, there are commands. It's impossible to say exactly which file causes the error. You or your webmaster would have to determine the error, or the developer of the application might be able to say whether the rules are defined correctly.)

---

We don't really have the know-how to work with this, but someone on here might be able to tell whether the mistake is on our side, or whether something is not correctly defined in limesurvey. Otherwise, we'll use a workaround.

Sorry for the double post. There's a relevant piece of information that I forgot to mention, and that I didn't want to get lost in my long post above after an edit:

It's not only the survey link for the broken token that doesn't work. We aren't able to display the participants either. Clicking on "Display participants" gives us an Error 500. We can add participants by importing a CSV, but we can't set them up correctly for sending them e-mail invitations.

Which German provider is that? Looks like you installed LimeSurvey inside a CMS directory. The provider is pointing out that htaccess files of LimeSurvey and the CMS might overlap and the rules might need to be merged at a certain directory.

If that would be the root cause I would expect the issue with every access.
Perhaps you use different kinds of surveylinks or there are different entry points to LimeSurvey.

I would recommend to keep webapplications separated.
If you have the CMS in the webroot, you cannot install LimeSurvey in a subdirectory without examining every htaccess file and rule and merge them. That is complicated and needs to be done with any update on any webapplication.

@jelo, we indeed have our LimeSurvey installed in the same CMS directory as our website (in a different subdirectory). I got back with the support of our provider, and they confirmed that this might indeed be the problem. Thanks for the hint. We will transfer our LimeSurvey application to a separate subdomain to keep them separate from the CMS. We will have to find some time to do that – but I'll definitely let you know whether this will solve this issue.