Wesley Alan Wright: Notes, Lessons, and Projects

Client reported tool (https://www.uvm.edu/htpasswd) wasn’t behaving.

Some time ago, the webteam decided to change their convention for providing friendly urls. They create a friendly alias in htdocs, and point it at a folder named website in the owners home directory. For example,

https://www.uvm.edu/~ugrsrch/ , files in /users/u/g/ugrsrch/public_html

https://www.uvm.edu/ugresearch/ , files in /users/u/g/ugrsrch/website

(Never mind that if both folders exist, these are now two distinct websites. Holy broken bookmarks and more, Batman.)

So, the password utility at

https://www.uvm.edu/htpasswd

needed to be updated to recognize the existence and priority of a website folder. this was actually pretty easy. The tricky part is the construction of .htaccess . Given a REMOTE_USER of kapoodle, it is easy enough to generate this, to force SSL:

SSLRequireSSL
ErrorDocument 403 https://www.uvm.edu/~kapoodle

But now our client wants http://www.uvm.edu/MyronKapoodle. How do I infer

SSLRequireSSL
ErrorDocument 403 https://www.uvm.edu/MyronKapoodle

turns out not to be an issue: On Mar 6, 2013, at 1:42 PM, Benjamin Coddington <bcodding@uvm.edu> wrote:

Wes, I don’t think you need to worry about forcing SSL for authentication
anymore.  A couple years ago we wrote an apache module that monitors all the
server’s responses looking for the WWW-Authenticate: Basic header, and if
the response would be sent un-encrypted the server instead hijacks the
response and turns it into a redirect to the same location over SSL.

This nicely eliminated the possibility of sending WWW-Authenticate: Basic in
plain text, and I think it also means you don’t have to worry about
SSLRequireSSL and .htaccess-https for authentication purposes.

Jim McGarry, Exam Proctoring center, sent me this question:

 This html has been working for years apparently up to the end of Fall 2012 semester; it calls a program to send email & to create a flat file in the directory it resides in that I download to create forms & update a database.

 

 

 

Now when I try to execute it I get

Scott Dellinger, Systems Architecture & Administration, Enterprise Technology Services, made note

The old server at cgi.uvm.edu was retired at the end of 2012.  This was announced in November and December to the it-announce and it-discuss mailing lists used to disseminate such information, though it does not appear you currently subscribe to either.  (You might wish to do so, in order to ensure you see IT service announcements.)  We also directly contacted script owners whose scripts we could determine were being actively used, though most of the remaining contents on this server were only being spammed anymore and so this was difficult to identify.  I’m sorry you were not aware of the change. It looks like your script is a derivative of FormMail.  We have a copy of FormMail running on a supported server, available on scripts.uvm.edu (see http://www.uvm.edu/it/utilities/formmail.html for details).  If this will work for you, then moving to use that would probably be your easiest option.  If not, then we have a new CGI hosting service that could be an option, though it works a little differently.  Just let us know and we’ll be glad to help.

Turns out ,Jim already has a “silk” server at

http://epc.w3.uvm.edu

created last October. See here and here.

the Bformmail2.pl script he was using had some additional features not found in formmail.pl He had a copy of this on backup drive, loaded it on his server. Nothing happened.

Apparently, form POST variables are not appearing in perl %ENV hash. I was able to prove this with this here link and this perl

#!/usr/bin/perl
use Data::Dumper;
use CGI;
print “Content-type: text/htmlnn”;
$query=CGI->new;
print “

";
print Dumper $query;

But no, say Ben:

Use $fcgi, as if it was an automagically created instance of CGI (because it is):

#!/usr/bin/perl
use Data::Dumper;
print "Content-type: text/htmlnn";
print "

";

The fcgi stuff on the server is setting up CGI, and is persistent across requests.  The requested perl script is executed per-request from a persistent fcgid handler

Oh, the fun we have.