• The forum software that supports hummy.tv has been upgraded to XenForo 2.1!

    This upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

[webif] Web Interface 1.4.x

Black Hole

May contain traces of nut
Is this not a perennial problem for anyone who likes to impose their own local CSS (and a reason for not bothering)?
 
OP
af123

af123

Administrator
Staff member
That's a change that came in with webif 1.2.7 back in February 2016. Links on the main menu go through the /go/ route so that plugins can re-route requests or add their own. Nothing has changed there recently.

Is it the trailing ? on the final URL that's causing you problems? That's only the query string so should be the same as the first URL.
 
That's a change that came in with webif 1.2.7 back in February 2016. Links on the main menu go through the /go/ route so that plugins can re-route requests or add their own. Nothing has changed there recently.
Well, it's only made itself known this week.
Is it the trailing ? on the final URL that's causing you problems? That's only the query string so should be the same as the first URL.
Fixed it.
Changed the "Applies to" dropdown from "URL" to "URLs starting with".

Thanks for your reply.
 

Black Hole

May contain traces of nut
Feature request: on the media management pages, for all files ticked provide a multi-file download option.
 

/df

Active Member
As reported by @Raydon and Matthew, there's a problem with Opt+ menu commands applied to recordings with '&' in the pathname.

At /mod/lib/jim/cgi.tcl line 70, query parameters are extracted as below and inserted into a tcl dict used by cgi_get:
Code:
        set pairs [split $input &]
Filenames, and in fact all externally supplied parameter values, need to be encoded in the HTTP request (eg & -> %26) and then decoded after splitting the query parameters.
Looking at /mod/webif/html/browse/script.js l.428
Code:
var menuclick = function(action, el, pos)                                
{                                                                        
        var file = $(el).parent().prevAll('a.bf').last().attr('file');   
        var efile = encodeURIComponent(file);                            
...
        switch (action)                                                        
        {                                                                      
...
            default:                                                          
                if (plugins.menu[action])                                     
                        plugins.menu[action](file);                           
                else                                                          
                        alert('Unhandled action: ' + action);                  
                break;                                                        
        }
}
Then in (eg) /mod/webif/plugin/sidecar/browse.js:
Code:
...
// Action taken when 'sidecar' action clicked on native recording.
plugins.menu.sidecar = function(file) {                           
        window.location = '/plugin/sidecar/web/?file=' + file;
...
Shouldn't the various .?menuclick() functions in /mod/webif/html/browse/script.js pass encodeURIComponent(file) rather than file? Or are plugins at fault for not calling encodeURIComponent() on the filename passed to them?

When I make the former set of changes, I'm able to invoke DecryptAds 'Run Analysis Now' successfully on a file with '&' in either its base name or its folder name, although strangely I had to do
Code:
chmod +x /mod/webif/plugin/detectads/web/runnow.jim
to avoid a "server error" response.

After thinking about this again, I think it's down to the plugins. There's no suggestion that the file parameter of the various plugin APIs is anything other than a system file name, so a plugin that wants to use it as part of a URI ought to sanitise it first, as below:
Code:
...
// Action taken when [whichever plugin] action clicked on native recording.
plugins.menu.whichever = function(file) {                           
        window.location = '/plugin/whichever/web/?file=' + encodeURIComponent(file);
...
What do affected WebIf/plugin authors (looks like WebIf, Sweeper? Sidecar, DetectAds) think?
 
Last edited:

prpr

Well-Known Member
Searches for CRIDs with '/' characters in them (as used these days by the BBC) don't work via items on the WebIf's Scheduled Events page.
Here's a fix:
Diff:
humax /mnt/hd2/mod/webif/html/sched/rpc # diff info.jim~ info.jim
--- info.jim~
+++ info.jim
@@ -68,7 +68,7 @@
        </tr>
"

-set crid [join [lrange [split [$event get szCRID] /] 1 end]]
+set crid [join [lrange [split [$event get szCRID] /] 1 end] /]
if {$crid != ""} {
        puts "<tr><th>"
        if {[$event isseries]} { puts "Series" } else { puts "Event" }
@@ -88,7 +88,7 @@
                set ev [string range $ev 1 end]
                if {$flag} { puts "<br>" }
                incr flag
-               set crid [join [lrange [split $ev /] 1 end]]
+               set crid [join [lrange [split $ev /] 1 end] /]
                puts -nonewline "<a href=/cgi-bin/epg/search.jim?"
                puts "crid=/$crid>
                    <img border=0 src=/images/421_1_00_CH_Title_2R_Arrow.png
Somewhere there's also a case-sensitivity problem as I've got things like /M/ABCDE in my database, whereas the current EPG has them as /m/ABCDE. The Humax seemingly doesn't care about this, but the WebIf's CRID search does.
 
Top