From john.thurston@alaska.gov Wed Jun 24 08:23:49 2026
From: john.thurston@alaska.gov
To: xymon@xymon.com
Subject: [Xymon] 4.3.25 - ouch (reverting to 4.3.22)
Date: Wed, 10 Feb 2016 12:23:51 -0900
Message-ID: <56BBAA67.3010602@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3431895788896058407=="

--===============3431895788896058407==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

My testing of the release candidate was obviously inadequate. My phone=20
rang off the hook after shipping 4.3.25 to my production server. I've=20
reverted it to 4.3.22 while I try to get a handle on the changes.

:: svcstatus refresh ::

I didn't see any mention of this in the release notes, but the page is=20
now being delivered with a 30-second _header_ refresh in place of a=20
60-second _meta_ refresh.

I assume the change in method is related to XSS protection changes, but=20
I don't know for sure. The shortening of the interval concerns me much=20
more than the change in method. I'd prefer the darned page didn't=20
refresh at all, but hard coding it to every half minute?  Ouch. Ick.=20
What's the business case here? Anyone who his visually monitoring a=20
single info page can hit F5 when they want a refresh, can't they?

:: XSS protections ::

It looks like the XSS protection bits inserted into http headers
> content-security-policy: script-src 'self'; connect-src 'self'; form-action=
 'self'; sandbox allow-forms;
> X-Content-Security-Policy: script-src 'self'; connect-src 'self'; form-acti=
on 'self'; sandbox allow-forms;
> X-Webkit-CSP: script-src 'self'; connect-src 'self'; form-action 'self'; sa=
ndbox allow-forms;

has broken several functions for me. The most important things are the=20
notes our operators use to figure out who to call. We insert some html=20
into the DESCR tag of hosts.cfg. This appears on the "info" page as a=20
link. The links are to static content served by the same Apache web=20
server. The tags are of the form:
> DESCR:"Important Server:<a href=3D/xymon/CNotes/ImportantServer target=3DNo=
tes>Reference notes</a>"

With Firefox, the links work. With InternetExploder and Chrome, the=20
links quietly fail to work. The Chrome console returns the error message:
   Blocked script execution in 'https://foo.bar.com/xymon-
   cgi/svcstatus.sh?HOST=3Dbb.bar.com&SERVICE=3Dinfo' because
   the document's frame is sandboxed and the 'allow-scripts'
   permission is not set.
Removing the "target" property from the A tag allows it to work. It=20
overwrites the info page, but at least it works :p It feels like a step=20
back to the 90's be forced into a single page that keeps getting replaced.

I don't know enough about the "content security policy". What are my=20
options to retain the named-window/tab capabilities?

:: svcstatus disable function ::

We are unable to enable/disable test from a host's "info" page. We can=20
do so from enadis.sh, but this is a lot harder for many of our users.

In Chrome, attempts to disable tests from the "info" page is generating=20
the same "frame is sandboxed" messages.

In Firefox, the attempts just don't do anything. There are messages in=20
the console
   Content Security Policy: The page's settings blocked the loading
   of a resource at self ("script-src https://x.foo.com").
so maybe the information necessary to build the form isn't even being=20
loaded.


--=20
    Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska


--===============3431895788896058407==--


From matt1299@gmail.com Wed Jun 24 08:23:49 2026
From: matt1299@gmail.com
To: xymon@xymon.com
Subject: [Xymon] 4.3.25 - ouch (reverting to 4.3.22)
Date: Wed, 10 Feb 2016 16:44:51 -0500
Message-ID:
 <CAE6TTt4n-VYhuVgs-tuVdYnON3V12uHbvvxCfoqG_Xm5H1UsTQ@mail.gmail.com>
In-Reply-To: <56BBAA67.3010602@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4308471437777177936=="

--===============4308471437777177936==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I can confirm that the enable/disable functionality isn't working for me
either when done from the info page. Selecting apply just doesn't do
anything (using Firefox). In Chrome, I'm seeing the same error messages in
the Chrome Console that John describes. I'm using the latest Terabithia
RPMs for RHEL 7.


I very much disagree with the idea of having to hit F5 every so often to
see a refreshed Xymon page, rather then it refreshing automatically.

If I have a Xymon page up on a monitor and then I am working on something
else on another monitor, I don't want to have to go over to the browser on
the other monitor and hit F5 every so often to refresh the page. I'd much
rather it refresh every so often automatically, so then I just have to look
over at the monitor every so often to look for any changes.

Where exactly are you seeing this refresh change (just curious)?

Why wouldn't you want it to refresh automatically? Isn't the idea to get
the most up-to-date info possible?

Personally, it doesn't matter to me whether it's every 60 seconds or every
30 seconds. 60 seconds worked just fine for me before.

Maybe J.C. can elaborate more on why the change in the time interval
happened.

Thanks.

--
Matt Vander Werf

On Wed, Feb 10, 2016 at 4:23 PM, John Thurston <john.thurston at alaska.gov>
wrote:

> My testing of the release candidate was obviously inadequate. My phone
> rang off the hook after shipping 4.3.25 to my production server. I've
> reverted it to 4.3.22 while I try to get a handle on the changes.
>
> :: svcstatus refresh ::
>
> I didn't see any mention of this in the release notes, but the page is now
> being delivered with a 30-second _header_ refresh in place of a 60-second
> _meta_ refresh.
>
> I assume the change in method is related to XSS protection changes, but I
> don't know for sure. The shortening of the interval concerns me much more
> than the change in method. I'd prefer the darned page didn't refresh at
> all, but hard coding it to every half minute?  Ouch. Ick. What's the
> business case here? Anyone who his visually monitoring a single info page
> can hit F5 when they want a refresh, can't they?
>
> :: XSS protections ::
>
> It looks like the XSS protection bits inserted into http headers
>
>> content-security-policy: script-src 'self'; connect-src 'self';
>> form-action 'self'; sandbox allow-forms;
>> X-Content-Security-Policy: script-src 'self'; connect-src 'self';
>> form-action 'self'; sandbox allow-forms;
>> X-Webkit-CSP: script-src 'self'; connect-src 'self'; form-action 'self';
>> sandbox allow-forms;
>>
>
> has broken several functions for me. The most important things are the
> notes our operators use to figure out who to call. We insert some html into
> the DESCR tag of hosts.cfg. This appears on the "info" page as a link. The
> links are to static content served by the same Apache web server. The tags
> are of the form:
>
>> DESCR:"Important Server:<a href=/xymon/CNotes/ImportantServer
>> target=Notes>Reference notes</a>"
>>
>
> With Firefox, the links work. With InternetExploder and Chrome, the links
> quietly fail to work. The Chrome console returns the error message:
>   Blocked script execution in 'https://foo.bar.com/xymon-
>   cgi/svcstatus.sh?HOST=bb.bar.com&SERVICE=info' because
>   the document's frame is sandboxed and the 'allow-scripts'
>   permission is not set.
> Removing the "target" property from the A tag allows it to work. It
> overwrites the info page, but at least it works :p It feels like a step
> back to the 90's be forced into a single page that keeps getting replaced.
>
> I don't know enough about the "content security policy". What are my
> options to retain the named-window/tab capabilities?
>
> :: svcstatus disable function ::
>
> We are unable to enable/disable test from a host's "info" page. We can do
> so from enadis.sh, but this is a lot harder for many of our users.
>
> In Chrome, attempts to disable tests from the "info" page is generating
> the same "frame is sandboxed" messages.
>
> In Firefox, the attempts just don't do anything. There are messages in the
> console
>   Content Security Policy: The page's settings blocked the loading
>   of a resource at self ("script-src https://x.foo.com").
> so maybe the information necessary to build the form isn't even being
> loaded.
>
>
> --
>    Do things because you should, not just because you can.
>
> John Thurston    907-465-8591
> John.Thurston at alaska.gov
> Enterprise Technology Services
> Department of Administration
> State of Alaska
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>

--===============4308471437777177936==--


From john.thurston@alaska.gov Wed Jun 24 08:23:50 2026
From: john.thurston@alaska.gov
To: xymon@xymon.com
Subject: [Xymon] 30-second refresh [was: 4.3.25 - ouch]
Date: Wed, 10 Feb 2016 13:02:34 -0900
Message-ID: <56BBB37A.6070005@alaska.gov>
In-Reply-To:
 <CAE6TTt4n-VYhuVgs-tuVdYnON3V12uHbvvxCfoqG_Xm5H1UsTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8932916692463231620=="

--===============8932916692463231620==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 2/10/2016 12:44 PM, Matt Vander Werf wrote:
- snip -
> I very much disagree with the idea of having to hit F5 every so often to
> see a refreshed Xymon page, rather then it refreshing automatically.
>
> If I have a Xymon page up on a monitor and then I am working on
> something else on another monitor, I don't want to have to go over to
> the browser on the other monitor and hit F5 every so often to refresh
> the page. I'd much rather it refresh every so often automatically, so
> then I just have to look over at the monitor every so often to look for
> any changes.
>
> Where exactly are you seeing this refresh change (just curious)?

This refresh has been moved from the _meta_ content of the svchosts page 
the HTTP _header_ . As such, "view source" will no longer reveal it.

> Why wouldn't you want it to refresh automatically? Isn't the idea to get
> the most up-to-date info possible?

Not in all cases. I want the general pages of hosts (like xymon.html) to 
refresh periodically, but there is no need to have them auto-refresh 
faster than I am running xymongen.

The issue I see is specifically with the "info" page produced by 
svcstatus.sh. I have it open when I'm studying a host for a specific 
reason. I would prefer that page not auto-refresh while I'm studying it 
trying to figure out a problem. If I want new information, I can refresh 
it. I might even want to keep it frozen and open a new copy in a new tab 
so I could compare the past and the present.

Does anyone put a single host's "info" page on a screen and leave it 
there for general monitoring? If so, why? What problem does it solve 
that looking at the parent page of hosts does not?

-- 
    Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska


--===============8932916692463231620==--


From matt1299@gmail.com Wed Jun 24 08:23:50 2026
From: matt1299@gmail.com
To: xymon@xymon.com
Subject: [Xymon] 30-second refresh [was: 4.3.25 - ouch]
Date: Wed, 10 Feb 2016 17:07:19 -0500
Message-ID:
 <CAE6TTt5yP8x3Xooa68_FA4VC2dwtw722iMoj4n75GV8mpnEqCg@mail.gmail.com>
In-Reply-To: <56BBB37A.6070005@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1259913480176489088=="

--===============1259913480176489088==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Ah. I didn't realize you were referring to the info page.

No, I completely agree with you here in regards to the info page.

My thoughts were more directed at actual status pages or other pages where
colors/icons might change, which it seems like you're in agreement with me.

Again, the refresh interval doesn't matter so much to me. However it was
done previously worked just fine.

--
Matt Vander Werf

On Wed, Feb 10, 2016 at 5:02 PM, John Thurston <john.thurston at alaska.gov>
wrote:

> On 2/10/2016 12:44 PM, Matt Vander Werf wrote:
> - snip -
>
>> I very much disagree with the idea of having to hit F5 every so often to
>> see a refreshed Xymon page, rather then it refreshing automatically.
>>
>> If I have a Xymon page up on a monitor and then I am working on
>> something else on another monitor, I don't want to have to go over to
>> the browser on the other monitor and hit F5 every so often to refresh
>> the page. I'd much rather it refresh every so often automatically, so
>> then I just have to look over at the monitor every so often to look for
>> any changes.
>>
>> Where exactly are you seeing this refresh change (just curious)?
>>
>
> This refresh has been moved from the _meta_ content of the svchosts page
> the HTTP _header_ . As such, "view source" will no longer reveal it.
>
> Why wouldn't you want it to refresh automatically? Isn't the idea to get
>> the most up-to-date info possible?
>>
>
> Not in all cases. I want the general pages of hosts (like xymon.html) to
> refresh periodically, but there is no need to have them auto-refresh faster
> than I am running xymongen.
>
> The issue I see is specifically with the "info" page produced by
> svcstatus.sh. I have it open when I'm studying a host for a specific
> reason. I would prefer that page not auto-refresh while I'm studying it
> trying to figure out a problem. If I want new information, I can refresh
> it. I might even want to keep it frozen and open a new copy in a new tab so
> I could compare the past and the present.
>
> Does anyone put a single host's "info" page on a screen and leave it there
> for general monitoring? If so, why? What problem does it solve that looking
> at the parent page of hosts does not?
>
> --
>    Do things because you should, not just because you can.
>
> John Thurston    907-465-8591
> John.Thurston at alaska.gov
> Enterprise Technology Services
> Department of Administration
> State of Alaska
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>

--===============1259913480176489088==--


From cleaver@terabithia.org Wed Jun 24 08:23:50 2026
From: cleaver@terabithia.org
To: xymon@xymon.com
Subject: [Xymon] Info/Refresh updated patch (was Re: 30-second refresh [was:
 4.3.25 - ouch])
Date: Wed, 10 Feb 2016 14:14:21 -0800
Message-ID: <f1c64fdc97d4a324f0a12a7fcc1497b6.squirrel@mail.kkytbs.net>
In-Reply-To: <56BBB37A.6070005@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7664756094134809665=="

--===============7664756094134809665==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On the refresh value, this was an unintentionally broad change.

CSP sadly catches the META HTTP-EQUIV "Refresh" tag as well as something
that is no longer honored, which requires moving it up into the actual
HTTP headers. This updated version of the CSP patch (from the last email)
does two things:
1) separate out info and trends pages from "regular" svcstatus pages. The
former won't be auto-refreshed
2) adds a previously-referenced XYMWEBREFRESH variable, which can be used
to configure this (default: 60s)

Going from 60s to 30s was an error on my part. I'd actually thought that
was the value for some reason...


On info pages not allowing _targets, that's also something caught by CSP.
The patch should fix this as well. Please verify if you can.


Regards,
-jc


On Wed, February 10, 2016 2:02 pm, John Thurston wrote:
> On 2/10/2016 12:44 PM, Matt Vander Werf wrote:
> - snip -
>> I very much disagree with the idea of having to hit F5 every so often to
>> see a refreshed Xymon page, rather then it refreshing automatically.
>>
>> If I have a Xymon page up on a monitor and then I am working on
>> something else on another monitor, I don't want to have to go over to
>> the browser on the other monitor and hit F5 every so often to refresh
>> the page. I'd much rather it refresh every so often automatically, so
>> then I just have to look over at the monitor every so often to look for
>> any changes.
>>
>> Where exactly are you seeing this refresh change (just curious)?
>
> This refresh has been moved from the _meta_ content of the svchosts page
> the HTTP _header_ . As such, "view source" will no longer reveal it.
>
>> Why wouldn't you want it to refresh automatically? Isn't the idea to get
>> the most up-to-date info possible?
>
> Not in all cases. I want the general pages of hosts (like xymon.html) to
> refresh periodically, but there is no need to have them auto-refresh
> faster than I am running xymongen.
>
> The issue I see is specifically with the "info" page produced by
> svcstatus.sh. I have it open when I'm studying a host for a specific
> reason. I would prefer that page not auto-refresh while I'm studying it
> trying to figure out a problem. If I want new information, I can refresh
> it. I might even want to keep it frozen and open a new copy in a new tab
> so I could compare the past and the present.
>
> Does anyone put a single host's "info" page on a screen and leave it
> there for general monitoring? If so, why? What problem does it solve
> that looking at the parent page of hosts does not?
>
> --
>     Do things because you should, not just because you can.
>
> John Thurston    907-465-8591
> John.Thurston at alaska.gov
> Enterprise Technology Services
> Department of Administration
> State of Alaska
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>

--===============7664756094134809665==--


From john.thurston@alaska.gov Wed Jun 24 08:23:50 2026
From: john.thurston@alaska.gov
To: xymon@xymon.com
Subject: [Xymon] Info/Refresh updated patch
Date: Wed, 10 Feb 2016 14:25:09 -0900
Message-ID: <56BBC6D5.3070300@alaska.gov>
In-Reply-To: <f1c64fdc97d4a324f0a12a7fcc1497b6.squirrel@mail.kkytbs.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6201546490888651686=="

--===============6201546490888651686==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 2/10/2016 1:14 PM, J.C. Cleaver wrote:
> On the refresh value, this was an unintentionally broad change.
>
> CSP sadly catches the META HTTP-EQUIV "Refresh" tag as well as something
> that is no longer honored, which requires moving it up into the actual
> HTTP headers. This updated version of the CSP patch (from the last email)
> does two things:
> 1) separate out info and trends pages from "regular" svcstatus pages. The
> former won't be auto-refreshed
> 2) adds a previously-referenced XYMWEBREFRESH variable, which can be used
> to configure this (default: 60s)
>
> Going from 60s to 30s was an error on my part. I'd actually thought that
> was the value for some reason...

These patches are helping. Thank you!

> On info pages not allowing _targets, that's also something caught by CSP.
> The patch should fix this as well. Please verify if you can.

To let the "target=3D_blank" option work, I needed to add "allow-popups"=20
to line 269 of lib/cgi.c

>     269         else if (strncmp(str, "svcstatus-info", 14) =3D=3D 0) csppo=
l =3D strdup("script-src 'self' 'unsafe-inline'; connect-src 'self'; form-act=
ion 'self'; sandbox allow-forms allow-scripts allow-popups;");

--=20
    Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska


--===============6201546490888651686==--


From cleaver@terabithia.org Wed Jun 24 08:23:50 2026
From: cleaver@terabithia.org
To: xymon@xymon.com
Subject: [Xymon] Info/Refresh updated patch
Date: Wed, 10 Feb 2016 19:52:15 -0800
Message-ID: <241777dd68807f38a42a0df5a220be0b.squirrel@mail.kkytbs.net>
In-Reply-To: <56BBC6D5.3070300@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6014708956715105705=="

--===============6014708956715105705==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, February 10, 2016 3:25 pm, John Thurston wrote:
> On 2/10/2016 1:14 PM, J.C. Cleaver wrote:

>> 1) separate out info and trends pages from "regular" svcstatus pages.
>> The
>> former won't be auto-refreshed
>> 2) adds a previously-referenced XYMWEBREFRESH variable, which can be
>> used
>> to configure this (default: 60s)
>>
>> Going from 60s to 30s was an error on my part. I'd actually thought that
>> was the value for some reason...
>
> These patches are helping. Thank you!
>
>> On info pages not allowing _targets, that's also something caught by
>> CSP.
>> The patch should fix this as well. Please verify if you can.
>
> To let the "target=_blank" option work, I needed to add "allow-popups"
> to line 269 of lib/cgi.c
>
>>     269         else if (strncmp(str, "svcstatus-info", 14) == 0) csppol
>> = strdup("script-src 'self' 'unsafe-inline'; connect-src 'self';
>> form-action 'self'; sandbox allow-forms allow-scripts
>> allow-popups;");
>


Can you test with the following two patches? I believe these should take
care of the outstanding issues. It seems like some versions of Chrome need
the allow-modals permission as well.


Regards,
-jc

--===============6014708956715105705==--


From john.thurston@alaska.gov Wed Jun 24 08:23:50 2026
From: john.thurston@alaska.gov
To: xymon@xymon.com
Subject: [Xymon] Info/Refresh updated patch
Date: Thu, 11 Feb 2016 09:48:27 -0900
Message-ID: <56BCD77B.8090909@alaska.gov>
In-Reply-To: <241777dd68807f38a42a0df5a220be0b.squirrel@mail.kkytbs.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7472463422661911038=="

--===============7472463422661911038==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 2/10/2016 6:52 PM, J.C. Cleaver wrote:
> Can you test with the following two patches? I believe these should take
> care of the outstanding issues. It seems like some versions of Chrome need
> the allow-modals permission as well.

I've taken a fresh extract of the .25 tar and applied these two patches.

I'm still testing, but it looks like:

Chrome "48.0.2564.109 m" will do enable/disable from 'enadis.sh' but 
neither from 'svcstatus.sh?SERVICE=info'

Internet Exploder 10 will do enable/disable from both locations

I'm doing more testing, but thought I'd get this report in.

-- 
    Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska


--===============7472463422661911038==--


From john.thurston@alaska.gov Wed Jun 24 08:23:50 2026
From: john.thurston@alaska.gov
To: xymon@xymon.com
Subject: [Xymon] Info/Refresh updated patch
Date: Thu, 11 Feb 2016 10:02:05 -0900
Message-ID: <56BCDAAD.3070104@alaska.gov>
In-Reply-To: <56BCD77B.8090909@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5401630491988458347=="

--===============5401630491988458347==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 2/11/2016 9:48 AM, John Thurston wrote:
> On 2/10/2016 6:52 PM, J.C. Cleaver wrote:
>> Can you test with the following two patches? I believe these should take
>> care of the outstanding issues. It seems like some versions of Chrome
>> need the allow-modals permission as well.
>
> I've taken a fresh extract of the .25 tar and applied these two patches.

It looks like links (such as I embed in the DESCR tags) on 
'svcstatus.sh?SERVICE=info' are not getting a referrer set on Chrome or 
Exploder. The referrer is present with FireFox.

I suspect it is back with the "content-security-policy" again. I'll see 
if I can identify the required pixie dust.

-- 
    Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska


--===============5401630491988458347==--


From cleaver@terabithia.org Wed Jun 24 08:23:50 2026
From: cleaver@terabithia.org
To: xymon@xymon.com
Subject: [Xymon] Info/Refresh updated patch
Date: Thu, 11 Feb 2016 13:15:40 -0800
Message-ID: <d7776798419d9b26bf8f3a866e39cc07.squirrel@mail.kkytbs.net>
In-Reply-To: <56BCDAAD.3070104@alaska.gov>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2308968573941637316=="

--===============2308968573941637316==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit



On Thu, February 11, 2016 11:02 am, John Thurston wrote:
> On 2/11/2016 9:48 AM, John Thurston wrote:
>> On 2/10/2016 6:52 PM, J.C. Cleaver wrote:
>>> Can you test with the following two patches? I believe these should
>>> take
>>> care of the outstanding issues. It seems like some versions of Chrome
>>> need the allow-modals permission as well.
>>
>> I've taken a fresh extract of the .25 tar and applied these two patches.
>
> It looks like links (such as I embed in the DESCR tags) on
> 'svcstatus.sh?SERVICE=info' are not getting a referrer set on Chrome or
> Exploder. The referrer is present with FireFox.
>
> I suspect it is back with the "content-security-policy" again. I'll see
> if I can identify the required pixie dust.


Thanks. I've been trying with the 'referrer' policy as well, but nothing
seems to have an effect.

I'm really beginning to hate the modern web >.<

-jc



--===============2308968573941637316==--