Suggesting tighter rules for accepting $urlget targets for binvars and filenames.

  • Block &binvar name containing spaces

    https://forums.mirc.com/ubbthreads.php/topics/266018/re-binvar-named#Post266018

    I'm only suggesting consistency between commands and identifiers, and I'm perfectly fine with NOTHING accepting a space inside a &binvarname.

    Related to the earlier thread about consistent validation of &binvar names, $urlget permits the name of a &binvar to contain a space and then triggers the callback alias with .state being 'ok'. While $bvar() and $bfind can handle that, /bset /bcopy /bwrite cannot, even if using $qt(target). I found this while trying to figure out a way to pass a commandline to the callback alias, and picked the wrong parm. When I made the 'target' parm be '&binvar text', $urlget created a &binvarname containing a space, and $bvar($urlget($1).target,0) $bvar($urlget($1).target,1-).text etc work like normal, but /bwrite /bset /bcopy failed.

    So $urlget could probably either reject this as an invalid binvarname the same way it does if the parm doesn't begin with '&' - or else call the callback alias with $urlget(id).state being 'fail' like it does if the f=target filename is global.txt
    .
  • possible new $urlgetdir identifier

    I'm wondering how useful it would be to 'sandbox' the $urlget target=f downloads by having $urlgetdir default to match $getdir for backwards compatibility, but being able to configure $urlgetdir to point elsewhere.

    For most identifiers and commands, the absence of a target path means the target points to $mircdir. The exception is for DCC downloads where the file downloads to $getdir(filename) which are able to be defined as pointing to $wavedir etc.

    However $urlget is a hybrid, where target-using-no-path means writing to $getdir even if $getdir(target-filename.filetype) points to somewhere else like c:\sounds\ or $mircdir $+ sounds. But if you use a relative path, then the base folder changes from $getdir to $mircdir.

    For example, if $getdir is H:\DOWNLOADS\ and $mircdir is C:\MIRC\ then f=target being test.txt downloads as H:\DOWNLOADS\test.txt but if the target is .\test.txt then it downloads as C:\MIRC\test.txt
    .
  • Block .. and possibly also . in f=target?

    I'm wondering if it's a good idea for $urlget to either reject paths containing .. folders, or to have something like a 'F' switch which either ignores the path in a target or makes the target invalid if it contains \ or /. If someone is using $urlget to download files from a file list generated somewhere else such as located inside a url retrieved from $urlget etc - without sanitizing them - there could be shenanigans like having the list salted with .\mirc.ini or .\scripts\file.mrc downloads\..\scripts\file.mrc etc.

    While there may be legit cases where a target containing a .. path folder would be legit, it may be a good idea for $urlget to not accept ..\ in paths. While the /fserve sandboxes downloads from escaping the homedir, /dcc send allows sending a path containing ..\

    If someone is using a downloads file list created by someone else, then even if $getdir is sandboxed to point to H:\downloads\, and $urlget would download the target parameter testfoo.dll as H:\downloads\testfoo.dll, the f=target parameter as ..\windows\system32\testfoo.dll would download to the c: drive if $mircdir is on the c: drive and if $isadmin is $true and if the quantity of ..\ matches the depth of $mircdir below the root.