Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
post upgrade, relative URL support broken
#1
Hi Dan,

I just upgraded to v4 from 3 and ran into a problem. In order to avoid opening a port in my router specifically for SIP, I had been running it at 

https://mydomain.com/sip/

I have one machine which listens on 443 and proxies to others depending on the URL, e.g. in this case to a PI running SIP for all URLs that start with /sip/

With version 3, this worked fine, but it doesn't work in 4. The first problem I tracked down is that base.html has

Code:
    <script src="/static/scripts/jquery-3.4.1.min.js"></script>
    <script src="/static/bootstrap-3.3.7/js/bootstrap.min.js"></script>
    <script src="/static/bootstrap-timepicker/js/bootstrap-timepicker.js"></script>

where previously it only had 

Code:
<link rel="stylesheet" href="$app_path('/static/...

I patched those manually, so now the main page shows up, but all the menu buttons are absolute URLs as well, e.g. the Options button goes to /vo

I could try tracking those links down, but it seems this is deeper than just changes to the HTML. Chrome dev tools reports:

jquery-3.4.1.min.js:2 GET https://mydomain.com/api/log?date=2020-06-09 net::ERR_BLOCKED_BY_CLIENT
jquery-3.4.1.min.js:2 GET https://mydomain.com/api/status 404 (Not Found)


Is there a way I can get the new version to work under /sip/? 

In the meantime I'll try changing my setup to use sip.mydomain.com instead.

Also, seemingly unrelated, while accessing it via local IP address rather than domain/sip I see a persistent error in chome developer tools:

jquery-3.4.1.min.js:2 GET http://10.0.0.128/api/log?date=2020-06-09 net::ERR_BLOCKED_BY_CLIENT

it looks like this fires and fails every 30 seconds.
Reply
#2
I'll take a look.

This may or may not be helpful:
https://github.com/Dan-in-CA/SIP/wiki/Reverse-proxy

There were a number of changes between SIP V3 and V4 to get SIP to run under Python 3 that may have affected things.

One major change was to update web.py to the version 4 that is Python 2 and 3 compatible. That also included moving to a new version of the cherrypy server that is provided with SIP (cheroot).

It is possible to use a different server with web.py such as nginx:
https://webpy.org/cookbook/uwsgi-nginx
<p><br></p>
Reply
#3
Yes, I should have mentioned earlier, I used the nginx configuration from your Reverse-proxy wiki page. I'm playing with it now, trying to get it to work with v4, but on its own I don't think that the proxy rules are enough, since the code doesn't use relative URLs.

I appreciate your taking a look. Switching to sip.domain.com isn't a great option because of the implications for SSL certificate renewal.

Quote:Also, seemingly unrelated, while accessing it via local IP address rather than domain/sip I see a persistent error in chome developer tools:

jquery-3.4.1.min.js:2 GET http://10.0.0.128/api/log?date=2020-06-09 net::ERR_BLOCKED_BY_CLIENT

it looks like this fires and fails every 30 seconds.


This was caused by an ad blocker - please ignore.
Reply
#4
When you open the SIP homepage and look at the page source what paths to you see for the hrefs that you added "$app_path(... to?

is the full path shown?

what happens if, instead of adding "$app_path(..." you remove the leading "/" from the hrefs?

Dan
<p><br></p>
Reply
#5
Hi Dan, thanks for the follow up. What I had tried was removing the leading slash, and that worked fine so that the main page would load its dependencies and work well. However, each of the buttons at the top - for programs, log, options, etc., still goes to a top level URL, and I didn't spend the time to track down where that's coded. To be honest I've rolled back to v3.2.55 for now.
Reply
#6
(2020 Jun 14, 08:31 AM)msambol Wrote: Hi Dan, thanks for the follow up. What I had tried was removing the leading slash, and that worked fine so that the main page would load its dependencies and work well. However, each of the buttons at the top - for programs, log, options, etc., still goes to a top level URL, and I didn't spend the time to track down where that's coded. To be honest I've rolled back to v3.2.55 for now.
I have been working on an update that makes all the links relative rather than pointing to the web root.
However some of the URLs still require the "/". The URLs that SIP uses are listed in the file urls.py in the SIP folder.

The update also has come Python code to change Python's working directory to the directory where the sip.py file is located. This allows SIP to be launched from any directory not just the SIP folder.

FYI the buttons on the top navigation bar are controlled from SIP > static > scripts > behaviors.js starting at line 54

there was some old code that prefixed the URLs in that file with "baseUrl +". the baseUrl was defined in base.html line 96.

Thanks for the info on the version that is working for you. It may help to figure out what caused things to stop working.

Dan
<p><br></p>
Reply
#7
I had a chance to look at this again. Changing baseUrl in base.html got all of the navigation working. Now the only issue left is with the toggle buttons, e.g. system on / system off, auto / manual, and the toggles for individual stations when in manual mode. This is functionality that I use quite regularly.

When I flip any of these toggles, the browser times out. After a manual refresh, I see that the toggle was changed and everything is fine. But I have to do that page refresh after each toggle.

The log shows:

10.0.0.104:41796 - - [29/Jun/2020 16:51:15] "HTTP/1.1 GET /sn" - 303 See Other

can you help me figure out what's driving that and how I might work around it?

Thanks.

i think the toggle redirects to http rather than https, because if I just hit reload it doesn't work, I have to add the https prefix.
Reply
#8
Confirmed. I redirected port 80 to 443 with nginx and can now use the toggles.

Two remaining anomalies:
1. toggling a station on in manual mode toggles off the others. I can't turn on two at once in manual mode.
2. run once > run now redirects to absolute URL /cr , so I will still have to track that down somewhere.


I fixed #2 in runonce.html

I'm not certain that #1 worked differently in the previous version, and it's not very important, so am calling this good enough and officially moving to v4.
Reply
#9
(2020 Jun 29, 03:31 PM)msambol Wrote: Confirmed. I redirected port 80 to 443 with nginx and can now use the toggles.

Two remaining anomalies:
1. toggling a station on in manual mode toggles off the others. I can't turn on two at once in manual mode.
2. run once > run now redirects to absolute URL /cr , so I will still have to track that down somewhere.


I fixed #2 in runonce.html

I'm not certain that #1 worked differently in the previous version, and it's not very important, so am calling this good enough and officially moving to v4.
Having only one station on in manual mode is a feature that was requested by another user.
<p><br></p>
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)