[Xymon] 4.3.25 - ouch (reverting to 4.3.22)

[Matt Vander Werf]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20160210/82987a79/attachment.html>