Issue: Using LDAP field throws HTTP 500 error when user is not logged in GLPI

[endlessterror]

I have a GLPI 9.1.6 installation, on which I have installed version 2.5.2 of the forms plugin. On this installation, I have GLPI accounts only for the IT personnel. I have not created any GLPI accounts for the users.

With that in mind, I created a form to be used for anonymous user (GLPI) ticket creation. Since I want to capture the user's email, I've tried playing around with the various ways supported by formcreator. I've created an email field, in a number of ways.

1. Setting email as an actor would be the best case, since it would also populate the ticket's requested field upon submission. Unfortunately, this does not work when the user is not authenticated in GLPI, see also issue Form Destination - Requester - Allow insert an e-mail from a Anonymous Users  #475 and an associated improvement request Improvement Request: Allow insert an e-mail from a Anonymous Users  #741.
2. Setting email as a text field is mainly used to at least gather the user's email. It will be embedded as an answer field. Apart from the obvious disadvantage (the ticket's 'Requested' field is not completed from this field in this case) there is another one: the user might mispell his/her email.
3. As an alternative to 2, I tried to test integration with LDAP. So I changed the email field to be a "LDAP Select" one. I also configured the attribute field to '(LDAP)Email'.

This ticket is concerned with case 3 above. What happens is this:

• if I am logged in as a GLPI user and visit this form, submitting the form works as it should.
• if user is not logged in GLPI, then I get an HTTP 500 error, with the following details:

[Thu Sep 28 09:53:23.306767 2017] [:error] [pid 13212] [client 192.168.0.209:60321] PHP Notice:  Undefined index: glpiactive_entity in /usr/share/glpi/plugins/formcreator/inc/targetticket.class.php on line 860, referer: http://my.server/glpi/plugins/formcreator/front/formdisplay.php?id=2
[Thu Sep 28 09:53:23.307345 2017] [:error] [pid 13212] [client 192.168.0.209:60321] PHP Notice:  Undefined index: glpiactiveprofile in /usr/share/glpi/inc/ticket.class.php on line 1586, referer: http://my.server/glpi/plugins/formcreator/front/formdisplay.php?id=2
[Thu Sep 28 09:53:23.951725 2017] [:error] [pid 13212] [client 192.168.0.209:60321] PHP Fatal error:  Uncaught exception 'ErrorException' with message 'in_array() expects parameter 2 to be array, string given' in /usr/share/glpi/inc/session.class.php:877\nStack trace:\n#0 [internal function]: warning_handler(2, 'in_array() expe...', '/usr/share/glpi...', 877, Array)
#1 /usr/share/glpi/inc/session.class.php(877): in_array('0', '0')
#2 /usr/share/glpi/inc/commondbtm.class.php(2593): Session::haveAccessToEntity('0')
#3 /usr/share/glpi/inc/ticket.class.php(450): CommonDBTM->checkEntity()
#4 /usr/share/glpi/inc/ticket.class.php(926): Ticket->canUpdateItem()
#5 /usr/share/glpi/inc/commondbtm.class.php(1065): Ticket->prepareInputForUpdate(Array)
#6 /usr/share/glpi/inc/item_ticket.class.php(105): CommonDBTM->update(Array)
#7 /usr/share/glpi/inc/commondbtm.class.php(853): Item_Ticket->post_addItem()
#8 /usr/share/glpi/plugins/formcreator/inc/targetticket.class.php(1119): CommonDBTM->add(Array)
#9 /usr/share/glpi/plugins/formcreator/inc/form_answer.class.php(853): PluginFormcreatorTargetTicket->save(Object(PluginFormcrea in /usr/share/glpi/inc/session.class.php on line 877, referer: http://my.server/glpi/plugins/formcreator/front/formdisplay.php?id=2

[btry]

Hi

I think I'll can easily avoid the HTTP 500 errur you described.

I'm aware that the actors fields does not work for anonymous users. Actually, this should be the same for any field which works with dropdowns or objects stored in database.

I cannot allow the fields to read any data from the database when no user is logged in because this may lead to a security issue. I think the best solution at the moment is to disallow use of some fields (and/or specific settings on them) to avoid form designers to create manfunctionning forms.

[endlessterror]

So the issue with LDAP access for anonymous is this:

I'm aware that the actors fields does not work for anonymous users. Actually, this should be the same for any field which works with dropdowns or objects stored in database.

Correct?

[btry]

I cannot tell you right now. LDAP field is even more different compared to other fields which gathers data from the database. I need to investigate your backtrace and the implementation of the LDAP field first.

[btry]

Hi

In latest versions the LDAP field is no longer usable with anonymous forms.

I close this issue.