When an agent is logged in to our osTicket instance it is possible to include attachments in the replies or internal notes.
However, when a registered user is logged in, when trying to add an attachment, you can quickly see the attachment being added (Progress bar going from 0 to 100 in a few moments) but then nothing happens, the attachment is not visible nor included in the reply.
I have obviously checked attachment settings a thousand times but all seems to be set correctly.
Strangely, when the user replies to a ticket via email, and attaches something, this works fine, the attachment arrives.
It's only not working for users logged in, while it works for agents logged in.
I'm very interested in how I should further troubleshoot this. I asked our PHP admin guy who has seen no errors in the PHP log that would point us in a direction.
Many thanks!
Hans


  • KevinTheJedi replied to this.

  • Hi Kevin,

    Took a while to respond cause I had to get with the guy who manages the webserver part (nginx). I gave him your suggestion to edit the nginx configuration and he said he did, made some corrections to what you gave us but after all now it all works again. First of all a big thank you for helping here and pointing us into the right direction.
    Just a question out of curiosity: Do you know or can you explain why we ran into this issue on nginx while on our testinstance, that is running on LightSpeed, this was not caused any issue and we didn't need to configure anything to make it work on that instance? When I asked the webserver admin why it was an issue on nginx he said:
    "Nginx was not issue, the issue was osticket needs special URI for ajax.php. You can see this URI was accessed: /ajax.php/form/upload/ticket/attach. but there is no such file under ajax.php folder.
    I dont know how LiteSpeed handle the URI which is not pointed to actual files".
    he also mentioned "Lightspeed has rewrite engine to handle such jobs to rewrite the "fake" request to actual location."

    My question, is this a bug in osTicket, accessing wrong URI, that we are now correcting with the nginx configuration or do you see this differently?

    Again, big thanks for your help!

    Have a good weekend. Cheers, Hans

    HansAlbers changed the title to Users cannot add attachments, agents can.

    HansAlbers

    Can you see the file information in the POST request when submitting the reply/ticket?

    Cheers.

      Hi Kevin,

      Thanks for that quick reply. I'm not sure I explained well enough what happens. I think the POST request you refer to is when submitting tickets via the API, right? I'm talking about entering a ticket or ticket reply when logged in as a user. I created a very small video to show what happens (1.5MB) but unfortunately the forum doesn't allow me to upload it, it says its too big, so I put it on Wetransfer at we[dot]tl/t-tFnCGIlnNd

      Doing exactly the same attachment in a reply or internal note when logged in as an agent is working fine. That's how I thought it cannot be an issue with our file permissions (we're storing attachments on the filesystem).

      Any hints? Many thanks, Hans

        HansAlbers

        I do not go to external sites for videos or anything like that for security reasons. It’s best to post screenshots in this forum directly.

        No, the POST I’m talking about is the one from the browser when you click the button to create a ticket or to post a message as a user. The easiest way to view this is to open the browser’s developer tools, click the Network tab, click the button to Preserve the logs, navigate to the help desk, upload the attachment, post the message/create the ticket, and view the POST request. You can see the Payload that should have the attachment information within it.

        Cheers.

          Ok let me first share two screenshots of the crucial moments from my video. I'm not talking about the attachment not being saved in the ticket after the user posts their reply. I'm talking about the actual moment the user is composing the reply, clicks on the "choose them" link, selects the desired file (a 23kB jpg picture in my testing). You get to see the progress bar indicating the file being uploaded, but then it immediately disappears, while normally the file then sticks below the message and is submitted with the message. It already disappears before submitting the message. So the message submits without the attachment.


          I've tried the network trace in my Chrome browser and after the failed attachement, the network log has catched the file that I tried to attach but I don't see a clear reason why it didn't end up into the reply on osTicket. Below screenshots from the network log just after the attempt to attach the file.



          All this works totally fine when logged in as Agent but not as user. Cheers, Hans

            HansAlbers

            Then that means the attachment upload failed or something is going on with the user session. Curious, do you have the setting that requires users to be logged in in order to view attachments?

            Cheers.

              We did but have switched that setting off, trying to see if it solves the issue but it doesn't. It does not matter which user is logged in. The issue is there for all our users.

                HansAlbers

                Hmmm, that is quite the conundrum. When you upload the attachment you should see a POST request. This POST request should return a response like {"id":123} on success or an error/etc. on failure. In your case, what do you see?

                Cheers.

                  Hope this is what you were looking for. When logged in as USER the response is:

                  file does not appear in the response field.

                  When logged in as Agent the response is:

                  and the file appears in the Response field,

                  Hope this makes any sense to you. I'm off to bed (Europe) but I will continue to work on this tomorrow.

                  Cheers, Hans

                    HansAlbers

                    You are supposed to click on the Response tab within the Network tab after clicking on the POST request.

                    Cheers.

                      Hi Kevin,

                      The response is not what it should be and after having tested from two different computers here, in the same network, same Chrome browser, we even get different results. On my computer:

                      on my colleague's computer:

                      From this response, it seems osTicket is redirecting to the agent login page?!?!

                      I have a test instance running on another server, where it works fine, on that server, the response is:

                      I must admit that instance has some differences. The osTicket version is exactly the same. But the one on which this attaching works fine is on PHP 8.3.13. while the one we have the issue with is on PHP 8.2.24. The other difference is that the system on which it works stores attachments in the database while on our problem-system (the real one) we store in the file system using the plugin. As said before, the puzzling part is that when logged in as agent, adding attachments works just fine, which uses the same filesystem plugin, I would think.

                      Like you say it is mysterious. I would understand that you don't have a solution right away. But any suggestions about further troubleshooting we could do? Like putting extra loggings in any of the php code? Appreciate your help!

                      Cheers, Hans

                      For what it is worth:

                      I found an option in Chrome developer mode to have it pause on exceptions and this is where it does so when attaching something logged in as user. When logged in as agent, no exception occurs.


                      The full error line is:
                      "SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON at Function.parse [as parseJSON] (<anonymous>) at xhr.onload (https://support.newland-id.com/js/filedrop.field.js?0375576:718:41)"
                      You can even see the picture of the attachment I'm trying to upload. after clicking the play (after the break) button this disappears right away.

                      Does this mean something to you?
                      Greetings, Hans

                        HansAlbers

                        That simply means it’s expecting the ID response (which is JSON format) but it’s getting HTML in the response instead. What else is different between the setups? Also, PHP 8.3 is not fully supported yet so that install will run into some issues at some point.

                        Cheers.

                          Which .php or .js is giving back the ID response normally?

                          About PHP version: We're having the issue on the instance running on PHP8.2. The test instance on 8.3. does not have this issue. I even installed the file system attachment plugin on the test instance like we have it on the production instance and this is working fine still on the test instance when using filesystem instead of database for attachments.

                          What we simply don't understand is why this all works fine for agent logged in, but not for user logged in. Litterally on the same osTicket instance. What can it make behave so different?

                          Greetings, Hans

                            HansAlbers

                            It's a mix of AJAX and PHP. Most likely the windows server or setup. I can't think of anything in the system would cause that.

                            Cheers.

                              At least we found out why the result on two differen PCs was different. One still was also logged in as agent, that's why the results were different. Now when both logged out as agent and ONLY logged in as USER, when trying to attach, we see in the Chrome debug screen that instead of doing the attachement the response from the attach action is a redirect to the agent login page. (/scp/login.php) which can be seen in this screenshot:

                              So there seems to be a reason why osTicket rejects an attachment upload from a user and we have no clue what that reason is. Any suggestions as to how to find out that? Are there other settings, not visible in the osTicket UI, that could affect this?

                              Thanks, Hans

                                HansAlbers
                                Could the permission be managed within the file system, given that his second system, which stores the database, is working fine?

                                    ramrajone

                                    That's what I was wondering but then I thought: "Why would it work for Agents and not Users if it was the filesystem?"

                                    Cheers.