Bugzilla – Bug 375
Alarm settings too hard to reach on web interface
Last modified: 2008-12-18 11:53:57 UTC
The one player setting that I typically change once per day is the alarm. This is at the end of the second page ("additional player settings"). Instead, it should be reachable without scrolling and without a second click, i.e. directly at the top of "player settings", or even in a more direct way.
Somewhat better with the new structure of the player settings. Unfortunately, my old trick of directly bookmarking what is now http://...:9000/setup.html? page=alarm&player=...&playerid=... elicits a 403 forbidden -- although this GET does not trigger any change!
this is due to a security fix that checks the referrer before allowing access to settings pages
Yes. What I'm saying is that the fix is wrong: It was meant to thwart random web pages that might include links to URLs that actually change settings. The link I described does not change anything and therefore does not need to be "forbidden". (The underlying problem, of course, is that the interfaces uses GET for changing state, but I'm not arguing that this should be fixed right now.)
What is likely to work at this point is to create a custom skin to match your need for instant alarm access. The setup link is valid from home.html so the 403 error would not come up if you were to add your direct bookmark to home.html of your favourite skin. To avoid having it overwritten when you upgrade, just copy the skin and rename the folder. Then choose the new skin from your server settings. If you are simply usign the lite skin, then you can just copy the home.html to a new folder and when you choose that skin, you will get the lite skin with your custom home.html. the secirty check may eventually be made more intelligent, but I personally dont' see the alarm link being put any closer than it is now to top level by default.
KDF, thanks for the proposal to write a skin. I agree that my original bug report is essentially closed by the new structure of the player settings. The limited intelligence of the security check is a new bug. Should I file this as a new bug number?
marking this as closed. the new auth mechanism for the security should solve the sideline problem mentioned here. If not, setting the security level to none should effectively revert to the old no security. please do refile as a new bug if this is not the case.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.