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.

Well, I couldn't leave it alone, but the command (edited for brevity):/bin/sed -i "/SYNOLOGY-REDIRECT/d" index.phpdeletes 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."

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

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?

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

Write a Reply...