[Hpr] HPR Web Submission Form: Ready for first review by someone who knows what they're doing...

Ken Fallon ken.fallon at gmail.com
Wed Apr 24 13:07:26 PDT 2013

On Wed, 24 Apr 2013 15:44:46 -0400
epicanis+hpr at dogphilosophy.net wrote:

> I finally had time to sit down and finish getting the last bits of
> the first iteration of the Web-based HPR Episode Submission Form
> working and tested. So far it provides what I would consider "minimum
> useful functionality" plus one additional feature.
> For me, "minimum useful functionality" means that it effectively
> provides to the HPR admins the same materials that are currently
> being submitted "by hand" to the ftp server. For HPR, this should
> make submissions more consistent to deal with. For submitters, you'd
> no longer need an FTP client nor need to worry about the correct
> format for the show notes file. 
> The web form guides the submitter into providing the necessary and
> useful information and allows upload of the show audio file, and
> optionally an "audio summary" file (to be prepended to the show for
> people who didn't read the feed before copying the file to their
> media player and wandering off, so they can decide if they are
> interested or not) and/or a single file of "supplemental" files
> (presumably images, example files, etc referenced in the show notes,
> collected into a tarball or zip file or whatever)
> Once uploaded, on the server side the script generates an obfuscated
> ID# for the submission, creates a save directory for it (as
> configured in the file) and saves the uploaded file(s) there, and
> creates a .txt file matching the format of the current show-notes
> file in the same directory. This provides a nice bundle of files
> equivalent to what the HPR admins are expecting from the FTP uploads
> right now for each episode, in a consistently-formatted way.
> In addition, the script generates as much of an Atom <entry> as it
> can with the given information and saves it as well. (The script
> cannot know some of the information required for the final <entry>
> such as the HPR show#, the file sizes for the encoded files, and the
> date the show will hit the feed - the script sticks some filler text
> in those spaces that should be easy to find-and-replace with the
> correct information at release time).
> The sample Atom feed file I mentioned in the last email was made with
> an <entry> directly generated from a test upload I did with the form
> (with the missing parts filled in by hand), and it is validated by
> the W3C online validator, so that part seems to be working. (If
> anyone is willing, I need to check that sample feed in as many
> "podcatchers" as possible. In particular, Atom allows multiple
> enclosures, meaning the current <entry> includes all of the media
> formats. I'm curious to verify that real-world "podcatcher" software
> is correctly handling that.)
> Currently, it does only slghtly more validation than the current FTP
> uploads get before an admin looks at them. Unmodified HTML is only
> allowed in a couple of explicitly configured fields. Filenames and
> paths are all internally generated so there shouldn't be any opening
> for malicious overwriting, etc. The save directory is expected to be
> configured to be outside of the webserver root, so the uploaded files
> shouldn't even be visible to anyone limited to web server access (not
> that this should really be an issue in our case). 
> I've uploaded copies of the two files that make up this system to the
> ftp server (ftp://hackerpublicradio.org ). "hprup.php" is the actual
> form. "takefile.php" is the script that accepts the uploads and
> processes the information.
> To use them, both the web server and PHP will likely need their
> configurations updated to allow larger file uploads (the web server
> will need to be told how large of a chunk of POST data it should
> accept, and php.ini will need upload_max_filesize and post_max_size
> updated). The form in hprup.php should indicate what PHP is currently
> configured to accept as a maximum file upload size. Both files should
> work fine if renamed, so long as you update the form to indicate
> whatever you rename "takefile.php" to.
> Anyway: if anybody here has time to look over them for any errors or
> potential problems I've missed, that would be helpful. I've only done
> enough testing so far to see that the system actually accepts data
> and files and saves the information the way I expected it to, so I
> haven't really started prodding it for holes much yet.
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

First let me thank epicanis for the excellent work.

Second. We REALLY need PHP peeps and anyone with upload experience to
follow along here. 

@epicanis, oOne thing before I leave the train. The upload is supposed
to be a complete valid atom element. So that I can do an XSLT transform
- (DeepGeek Goes Wild !)


More information about the Hpr mailing list