ForceSFV - Block uploads until .sfv is uploaded

[PopWeasel]

I looked for an answer to this but didn't find anything. I would like to have the function of blocking files uploaded in dirs until the .sfv is upped, based on file extensions. So you could also have exempt file extensions. There was a script for Raiden that did this perfectly called isSFV by mr_F but it's not ported to ioFTPD.:(
Here is the .ini file contents for isSFV to give you an idea of what I'm talking about:
#seperate each entry by a comma in this file
#ie: block=FLT,DEViANCE (yeah right hey :P)
#
# note: if the block key is empty all files will be banned
# it is set to an impossible filename so that nothing is blocked
# once you enter your own values in this key you can delete what i wrote there
#
#
raiden_path=C:\Program Files\RaidenFTPd
allow_exts=nfo,m3u,diz,zip,mpg,jpg
block=?
exclude_path=C:\Program Files\RaidenFTPD\FTPROOT\nrsfvtestserver\un
#
#
;end_ini ## this line is necessary, do not remove!!
So I guess I'm asking:
1. Is there a script like this for ioFTPD that will block files based on file extensions?
-or-
2. Will mr_F port isSFV to ioFTPD?
-or-
3. Will somebody else make one that will do this?
:D
If you're interested in taking a look at isSFV, you can find it at http://nrscripts.staghosting.com/rdn-scripts.htm
Thx for your help.;)

[neoxed]

ioBanana does this, wouldn't be very difficult to write in TCL either. If you don't use ioBanana, I could easily make you a TCL to do it.

Just let me know. :)

[PopWeasel]

That would be awesome if you could. The thing is, I do use ioBanana but I have a need for file extension based uploads blocking as opposed to dir name based uploads blocking, which is what ioBanana does. On IRC, occasionally people need to send me things like long irc logs (more text than they could send without flooding off in other words) or this or that file. Some ppl can't dcc send because they're behind a router that doesn't handle dcc cmds properly. So FTP transfer is the best way. Right now I'd either need to have them make an .sfv for their .log file (dumb imo) or tell them to make a dir called /covers/ or /sample/ and upload into there (also dumb imo for this situation).

If we had a file extension based uploads blocker, we could just set certain file extensions as exempt like log,txt,jpg,etc...:)

Also, something else that is nice is having a helpful msg when an upload is denied because a user hasn't uploaded an .sfv yet.

ioBanana-ioFTPD msg:
553 You must upload the .sfv file first.

isSFV-RaidenFTPD msg:
426-Upload sfv first.
426 Upload denied by external policy.

Something like that..

[neoxed]

If I understand you correctly, you want a setting to be able to ignore certain extensions and check for the sfv if the file extention is not in the ignore list?
For example:

set sfv_force_ignore "log txt jpg"
And check all file extensions except those listed in "sfv_force_ignore"? If no extension is found on the file, would you like it blocked or allowed?

I as well do the same thing, if I can't dcc them a file I put it on the FTP and tell them to grab it there. Except, I upload things like that to /Requests/ where I don't have NFO/SFV forcing.

What about just removing the force checks on the /Requests/ directory or a sub-directory in /Requests/ for this purpose. On other FTPs, I've just seen a "/Requests/NoCheck/" directory used as a "dropbox" for various files.

These are just a few alternative solutions, if you're interested in that script, let me know. ;)

[PopWeasel]

Yes, I'm interested in a script which will block uploads until there is an .sfv in the dir. But it must also have in the config file a setting where siteops could specify which file extensions to allow to be uploaded without any .sfv first. Your example of
set sfv_force_ignore "log txt jpg"
..would work perfectly.
As for your question of what if a file has no file extension, should it be allowed or blocked - I think it should be blocked, as the only files I can think of that have no extension are *nix style files (like README) which are easy enough for anyone to turn into win32 style by adding .txt to (or .msg or whatever). If it's not an ascii file and has no extension they could always .zip compress it since .zip would be on the sfv_force_ignore line for 0day stuff anyways.. If you or anybody else thinks of a use for a file with no extension maybe it can be allowed. Better yet, that could be an option in the config like such:
#Allow files with no extension when no sfv.
set allow_no_extension 0/1
hehe, not sure if that made sense technically but u get the idea.:p
And I don't have a Requests dir..I'm using site request from ioA for that.

[neoxed]

Finished..try it out, let me know if it's done as you wanted it. If there's any bugs or unexpected behaviour let me know as well.

Renamed the thread, I'll just use this as the support thread. If anyone has any ideas or feature requests, you can have the final say on them, as this is your request. ;)

http://www.ioftpd.com/scripts/script.php?id=115

[PopWeasel]

Wow NeoXed, it looks very nice.:) The only thing I can see wrong at first glance is this part, it looks like a small typo:

### No Extention
# - Block files with no extension?
# - 1 = Allow / 1 = Disallow
..one must be 0..;) :p Also, could we change the wording there so instead of Allow/Disallow which is confusing because users might not be sure if that means Allow/Disallow setting (Allow meaning block files with no sfv) or Allow/Disallow files (Allow meaning allow files with no sfv). Maybe Enable/Disable would be clearer or even an
#Enable = block files with no sfv
..small explanation to clarify.:)

I love how you outlined the "upload denied" msg to users..it will be very clear to them why their upload was denied.:) I can't wait to try this.;)

[neoxed]

Ahh you're right, I renamed that variable just before I posted it, and I forgot to update the comments.

It should read:

### No Extension
# - Block files with no extension? (ex. README)
# - 1 = Block / 0 = Allow

set BlockNoExt 0

[PopWeasel]

The script is working perfectly for my needs now. I thought of another way to expand its flexibility but perhaps it would only make it more complicated and I like it how it is now. Well if you want to know the idea I had, it was to allow exemptions based on user/group/flag. Perhaps useful for certain users who are not up to speed with certain things and just want to send you a file (friends, family, etc..). But like I said, the script is working perfect for my needs now so it would be totally up to you if you want to implement that extra feature, I only thought of it now that the script is done and working so nicely.:)

btw, I changed the 2 output msg areas of the script slightly and only post here because I think you may like it as well

iputs -noprefix "553-,-\(NoExt\)---------------------------------------,"
iputs -noprefix "553-| No extension found, file not allowed. |"
iputs -noprefix "553 '------------------------------------\[ForceSFV\]-'"
and
iputs -noprefix "553-,-\(NoSFV\)---------------------------------------,"
iputs -noprefix "553-| You must upload the SFV first. |"
iputs -noprefix "553 '------------------------------------\[ForceSFV\]-'"

...this shows the script name + an abreviated reason for the denied upload in the outline of the msg for both denied reasons.

I'll let you know if I notice any strange behavior from the script as I'll be using it for sure.;) Thanks again for your work in creating it.:) :)

[FTPServerTools]

hmm why would someone want to block uploads until there is an sfv? It doesnt make sense. A good script can just as easy check the files when the sfv is uploaded at the end or somewhere in between.

[PopWeasel]

Yep you're probably right that a good sfv checker can check the release no matter when the sfv was upped. But believe it or not there are actually some lazy mofos out there who try to up a big ass thing as one big file which occasionally will xfer corrupted which is just a waste of time+bw. Ensuring that the upload is blocked until an sfv is in the dir first is a nice way of encouraging these ppl to xfer large files properly..by making a multipart archive and sfv.:o