Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Confirmation Page for a new ticket doesn't display a good ticket #

My distribution works as expected in every other way including the confirmation email having a good ticket ID. Unfortunately the new ticket confirmation page simply displays:

"...A support ticket request # XXXXXX has been created and a representative will be getting back to you shortly if necessary. ..." where the # XXXXXX should be the new ticket ID.

IF the user gets the confirmation email (not at all certain given deliverability and spam filters) the email confirmation has a good ticket number and they can either respond via email or the web interface. Unfortunately those users that didn't get a confirmation email have no way of looking up their ticket and conversing via the web interface and cannot reply via email.

I'm running version on an Windows/IIS server.



    Although I searched on this site I couldn't find the equivalent of this discussion thread which answers the question above:

    In short this is a purposefully introduced error (as defined by either coding error OR process error! in other words a mistake IMHO) and you need to either get rid of the Ticket reference altogether or go the less secure route and change the code in /open.php.

    array_fill(0, 3, 'XXXXXX'),
    array_fill(0, 3, $ticket->getExtID()),
  • @scatterbrain - you're totally mistaken as to why the ticket number is masked. 

    The #XXXXXX is a placeholder to blank out the real ticket number. It is necessary due to how osTicket authenticates users by using email and ticket ID. For instance, if someone submitted a new ticket under your email address and the ticket ID were to be shown on the thank-you page, that someone could then log into the system with your email and the new ticket number and view previously tickets (if the feature is enabled). Therefore, we opted to show the ticket number with all X's if it were displayed on the thank-you page.

    That said, the upcoming version introduces client-login with username and password - making it possible to display the ticket number on thank you pages. 
  • edited April 2014
    Whilst you did explain the security reasons beautifully, my reference to it being an error is the fact that there is no sensible reason to display a placeholder which misleads and requires modification on a default installation.

    There is no explanation in the admin interface nor even note within the pre-configured page.

    My guess is that 90% of newbie installers will do exactly what I did, waste considerable time trying to figure out why an operational ticket system isn't displaying the ticket number using what looks like correct variable syntax.

    Even the inclusion of an in line explanation (needing to be deleted before going live) would be sensible since clearly that page shouldn't be used live without being modified.

    It's not a coding error it is an error in judgement.

    BTW I have implemented the code change I posted above, so are you suggesting turning off the ability to view previous tickets will mitigate most of the security issue?
  • I've tried to write 5 responses to this, and all of them strike me as me being negative, so if this comes off as harsh please add a little salt.

    Displaying the ticket number would be like displaying the password.  With the addition of the Collaborators features (in 1.8.1) more than one person could (read as will) have the password.  This is intrinsically insecure.  So while you may be of the opinion that there is no sensible reason for this change I feel that you are in fact mistaken.  The next version (which was 1.8.2 until it was decided that there were too many new things in it to be a minor update and so was changed to) 1.9 it will start working again.  It's been mentioned here on the forums (by me personally) more times that I can remember. So much so that I added it to the FAQ that you linked.
  • No, I don't perceive it as negative at all so don't worry about that. I think there is a slight misunderstanding. I do agree with you that displaying the ticket ID in the default installation with default options would be like creating functionality to let people hack others' support history.

    For that reason, when I implemented the code snippet above I also disabled the ability to view other tickets from the same email.

    What I was trying to do was to point out that the current default of having it display a placeholder without any notes isnt sensible. Either you guys should:
    1. Include notes in the note section of the Thank You page, or even inline notes within the displayed HTML, making it very obvious that the %{ticket.number} is a placeholder and will not work. So the user should either delete it or make the relevant code and option changes as I did
    2. Default disallow the ticket id to work with an optional enable, not allowing that enable unless you also disallow the ability to view other tickets with the same email. Ideally with a note on the other option explaining the security issues.

    This isn't a minor point either. I dont know about your email delivery rate but I'm happy if I get around 50%. If you dont have a ticket ID on the web page then around 50% of my users are also unlikely to receive ANY follow on email updates on their ticket. That leads to the obvious conclusion that I will not service 50% of my users and potentially lose them! Nothing pisses off users more than the perception they are being ignored.

    Separately but in addition to this, any newbie like myself will then spend hours trying to get the system to "work" when it is already working to specification! That seems an unnecessary waste of time when all you have to do is add some notes into the data defining the Thank You page!

    I'm going to the effort of writing this up not because I'm an arrogant, opinionated and naive user (I am), but because I really think osTicket is fantastic (better than many paid ticket systems I have used) and I want it to become better!
  • Feedback is always a good thing. :)  Thank you for your comments.
Sign In or Register to comment.