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-0910052141MySQL Version: 10.0.30PHP Version: 5.6.30PROBLEM DETAILS:Previous system access was via: support.mydomain.com/osticket/uploadThe 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.

    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 OnRewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteCond %{REQUEST_URI} (.*/api)RewriteRule ^(.*)$ %1/http.php/$1 </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!

    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

    The comment was meant for @[deleted]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 lolOkay, 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.phpAlthough 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.

    6 days later

    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.10MariaDB - 10.0.30PHP 5.6.30

    I think I just found the problem. In  upload/index.php the first line after <?php isheader('Location: http://'.$_SERVER.'/osticket/upload/scp');die();//SYNOLOGY-REDIRECTIt'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.

    @[deleted] 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.