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

URL Rewrite Problem after upgrading Synology-hosted osTicket Package

OVERVIEW:
After upgrading a fully-functioning osTicket system to the latest recommended version (this is a package specifically compiled by osTicket.com for Synology Diskstation), the system is failing due to URL rewrite problems. Of course, Synology disavows supporting anything to do with the osTicket package (even though Synology publishes the package and even though I suspect this problem is caused by a failed interaction with the Synology system).

ENVIRONMENT:
osTicket Version: v1.10 (901e5ea) - "Up to date"
Web Server Software: Apache/2.2.31 (Unix) mod_fastcgi/mod_fastcgi-SNAP-0910052141
MySQL Version: 10.0.30
PHP Version: 5.6.30

PROBLEM DETAILS:
Previous system access was via: support.mydomain.com/osticket/upload
The system redirects to https (if it wasn't already included in the typed URL).
The system then rewrites the URL to http://192.168.24.201/osticket/upload/scp/
(NOTE: 192.168.24.201 is the host system's (a Synology Diskstation, in this case) DMZ IP)

Obviously, rewriting the URL to an internal IP address isn't the correct behavior and is the main cause of grief. I've searched high and low for a solution, but I don't know why or how osTicket is changing the URL in this way. Any hints would be greatly appreciated.

Comments

  • osTicket isn't changing the URL.  I think that your Apache is (or a .htaccess)

    Also I'm not aware of the devs packaging anything specifically for Synology.  I think Synology might do that themselves.
  • Check helpdesk_url in the %prefix%_config table. Also you should check the .htaccess file to see the rewrite rules.

    (this is a package specifically compiled by osTicket.com for Synology Diskstation)
    I'm not aware of any package that we have compiled for Synology. We don't compile special packages for people, it's typically done by the company themselves.
  • I stand corrected about the compiler. In the advertised package, it says the "Developer" is osTicket.com and the "Publisher" is Synology Inc. In the end, it unfortunately opens the door to Synology support pointing their finger at osTicket since they didn't develop the package. A lame excuse on Synology's part, but I digress.

    I'm not sure where the %prefix%_config table is. However, in Admin Panel > Settings > System > General Settings > Helpdesk URL: https://support.mydomain.com/osticket/upload/

    I found five .htaccess files in the /web/osticket/upload path:
    ./apps/
    ./api/
    ./pages/
    ./scp/apps/
    ./include/

    From what I can tell, they are all the same (except for the one in ./include) and read:
    <IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.*/api)

    RewriteRule ^(.*)$ %1/http.php/$1 [L]

    </IfModule>

    The one in ./include is:
    Deny from all


  • I just discovered this problem myself. Apparently all my "users" could not login because they were being redirected to the wrong login page. I had not noticed because I always login as an agent. I was wondering why no one was submitting tickets!
  • edited July 12
    The %prefix%_config table is in your database. Find the helpdesk_url column.
  • You mean like the image attached? Yeah, that doesn't solve anything unfortunately. It does say where it should go for a normal client login, but instead it redirects to: "https://192.168.200.55/osticket/upload/scp/" which is the agent login page.
    Helpdesk_URL.jpg
    628 x 139 - 24K
  • The comment was meant for @fzs122
    What redirects to the Agent Login? The New Ticket template? When the user types your url?
  • Thanks again for everyone's help thus far!

    KevinTheJedi, sorry for my delay. I found out I had to install yet another "3rd party" package in Synology in order to read the osTicket tables.
    In the "ost_config" table, the "helpdesk_url" is https://support.mydomain.com/osticket/upload/
    It shows a last updated date that matches when osTicket was originally installed on the server (2015).
  • Man they really make it difficult don't they lol

    Okay, then it has to be a rewrite rule somewhere or the domain isn't set up properly. I would ask Synology for all .htaccess files you have on your server and see if any of them contain a rule that sets the domain to the IP. Also I would make sure your domain is set up properly. I hope you can get this resolved!
  • So I've been tinkering with the settings a little today to try to resolve the issue. On a whim, I changed the Helpdesk Url (via the admin GUI) to: https://support.mydomain.com/osticket/upload/view.php
    Although it adds a couple of clicks for an "agent" login, at least it seems to keep the URL stable with both the https and the FQDN of the system. I'm going to leave it like this for a while and see how it goes.
  • I would take out the 'view.php' part (leaving the trailing forward slash alone) making your URL 'https://support.mydomain.com/osticket/upload/'. The system will use this as your base URL for things. For example, in templates you can reference %{url} and it will give you the correct URL to your helpdesk!
  • I totally understand your recommendation. The 'https://support.mydomain.com/osticket/upload/' format for the Helpdesk Url is the certainly the best practice. It is just that, through my shot in the dark tinkering, I found that appending the extra 'view.php' part seems to resolve the issue where the FQDN gets changed to the internal IP. 

    I really like the use of the %{url} that you suggest. I updated my email templates and found a separate issue. Now the text of the link is the Helpdesk Url that is specified in the "ost_config" table (in my case, the link currently includes the 'view.php' part, however when I hover over or click the link it takes me to 'https://support.mydomain.com/osticket/upload/' I traced the problem to the embedded link. i.e. When I click literally on the "%{url}" when editing the template, I get an option to "Edit" or "Unlink" the link. Since I want the link to also be "%{url}" I set the URL to match the Text. Now both are set to "%{url}" (without the quotes). However, when I click "Edit" to save the change to the URL field, it converts to %%7Burl%7D. 

    I can't seem to win for losing. I guess I'll change the URL link value to https://support.mydomain.com/osticket/upload/view.php
  • OK. After exhaustive testing, I agree that I must use the 'https://support.mydomain.com/osticket/upload/' format for the Helpdesk Url. Reason being that anywhere else that %{url} is used "breaks" when I change it to something else. Sigh.
  • I'm having the same problem as j2blue.  On a Synology box, the link 10.1.10.100/osticket/upload to the support center is being redirected to 10.1.10.100/osticket/upload/scp/login.php, the admin login. This just started happening with the 1.10 version. I can get to the knowledgebase without a password with the link 10.1.10.100/osticket/upload/kb but the link /osticket/upload/index.php will redirect to /osticket/upload/scp/index.php which then redirects to the login.

    A cursory glance at the code for upload/index.php looks like the normal support center landing page, so I don't know where this redirection is coming from.  I'm not well-versed in web servers.

    I'm using (according to phpmyadmin):
    nginx/1.11.10
    MariaDB - 10.0.30
    PHP 5.6.30
  • edited July 19
    I think I just found the problem. In  upload/index.php the first line after <?php is
    header('Location: http://'.$_SERVER['SERVER_ADDR'].'/osticket/upload/scp');die();//SYNOLOGY-REDIRECT

    It's obviously been added by Synology (but not that obvious to me since I've been looking at the file for a better part of 2 hours). I first tried just taking out the /scp but that didn't work, so I just commented the line out and it seems to work the way it used to.  Of course, this may cause a domino effect somewhere else.  I don't know if this will help with the URL changing to IP problem the original poster has, but worth trying. 

    I wonder if Synology's changing from Apache to nginx server that I've been reading (but not really understanding yet) has anything to do with this line being added? Maybe somebody can enlighten me.

    EDIT: Yup, that line was not in the index.php before I upgraded to 1.10 a couple of weeks ago.  I found it on my backup.  Makes you wonder what other edits there are.
  • @dmitchell Thank you for sharing your findings and workaround! I'm checking with Synology support to see if anyone knows why that line was added.
  • According to Matt at Synology Support (Ticket: #1107806), I must have modified the upload/index.php file and caused the problem myself. Here is the response I received:

    We do not have any information on why that was added, but as there have been no other reported cases or known issues, nor are there any updates that would modify user files we do not believe this could have been caused by an update published by us. The only way that file could have been modified is by user intervention.


  • Say what!? So the line just appeared magically? With the 'SYNOLOGY-REDIRECT' comment? I don't know enough about PHP to add that line myself let alone doing it in the last few weeks when I upgraded. I downloaded the 1.10 upgrade from Synology's Package Center.  Someone is not owning up to this.  But at least my osTicket installation is working again, so far, and it's not a mission-critical app when (I mean if) it breaks again.

    Thanks for the update.  Hope your osTicket starts working again.
  • I found this line in the upload/include/upgrader/done.inc.php file:

    exec("/bin/sed -i \"/SYNOLOGY-REDIRECT/d\" /var/services/web/osticket/upload/index.php", $execOutput, $execStatus);

    I don't know what this does nor do I have time right now to research it, but it's pointing to the index.php file previously in question. There is also a directory called 'synology_added' under the volume1/@appstore/osTicket directory that is dated in May of this year.  I don't know why I think this, but I assume Synology may have added it. It has a few files in it, but I don't know what they do either.  I also assume they are installation files.
  • edited July 21
    Well, I couldn't leave it alone, but the command (edited for brevity):

    /bin/sed -i "/SYNOLOGY-REDIRECT/d" index.php

    deletes a line with "SYNOLOGY-REDIRECT" in index.php and writes the file back to itself.  I guess this didn't work with my installation, but obviously somebody somewhere (Synology) is modifying files.  Therefore the statement from Matt at Synology: "...nor are there any
     updates that would modify user files..." is incorrect.  I don't know why they, or anybody, can't just say: "We did that, it didn't work, now let's try to get it fixed."
  • @dmitchell Thanks a ton for tracking this down and posting your findings. I'd be lost (and my osTicket would still be broken) without your assistance. I'll share the info about the upload/include/upgrader/done.inc.php file and perhaps finally convince Synology that THEIR code contributed to the problem so that they can address the bug.
  • edited July 22
    So I guess this fixed your URL rewrite to IP problem you were originally having?  Glad I could help.  I'm truly a noob at this linux stuff. I learn just enough to fix my current problem, then immediately forget it!  That's why I've been using osTicket to catalog a lot of my IT solutions because I can't remember things like I did in my 30's.  I've written some PHP but am by no means an expert as per my previous posts.

    We got two birds since I was trying to fix a different problem than yours.  My search just led me to this discussion thread and the one poster who had the exact same problem I was having.  I'm not using a URL but I guess the "Redirection" phrase in the title caught my attention.

    Thanks for following up with Synology.  Hopefully they will get it straight.

    PS. How do you tag a person in these discussions like you did me (@dmitchell) in your reply?
  • @dmitchell works, just type the @ symbol followed by the username.
  • I'm just checking back in on this thread and noticed what may be the source cause of the problem and the solution. Thanks to everyone who worked on this. I will give the fix a test drive and see if that fixes it for me. 
Sign In or Register to comment.