this document covers web hosting on kanga.binghamton.edu, the server that has replaced both bingdev (departmental/office sites) and bingweb (personal faculty pages). if you managed a site on either of those before, it now lives here on kanga. please start referring to it as kanga going forward.
.htaccess control mechanism for password protection.
this doesn't work the same way with nginx. see below for how to get equivalent behavior.
kanga exists to keep existing bingdev/bingweb sites running. if you have a site on kanga you should start thinking hard about moving it for the long-term. we're not looking to grow this server or add new sites/services to it. if you're setting up something new, it doesn't belong on kanga.
personal web pages (hosted under your own account):
ssh yourNetId@kanga.binghamton.edu
log in with your normal ad/campus credentials. you'll land directly in your home directory and your site
content lives in the folder public_html underneath that. edit it there like you always have.
departmental / office sites (vhosts):
vhost content lives at /local/htdocs/<vhostName>. your normal ad account does
not have access to this path. to edit a vhost you'll need a separate local
account on kanga — use the vhost account form to check whether one
already exists for your site and, if not, request one. that same page lets you change the
password on a vhost account you already have.
basic auth (username/password restriction) isn't real security — the credentials are sent base64-encoded, not encrypted, so treat it the way you'd treat a lock on an office door, not a safe. host-based restriction is a bit more solid, but keep in mind that anyone with an account on kanga can read files directly off the filesystem regardless of what the web server enforces. if something absolutely cannot be seen by the wrong person, it doesn't belong on a kanga-hosted page, full stop.
if you're coming from the old bingdev/bingweb/apache world, you may remember doing this with a
file called .htaccess. kanga runs nginx, which doesn't read those files at all — but
don't worry if you've never touched one either. there are now two ways to restrict a site, and
which one you use depends on what kind of site it is.
if you want to put a username/password lock on your own page (~yourNetId), you can do
this entirely yourself, right now, with no form and no waiting on us. log in to kanga over ssh and
create a file named .htpasswd, either directly in your home directory or inside
public_html. as soon as that file exists, kanga automatically starts asking for a
username and password before displaying your page.
to create that file, run one of the following on kanga:
htpasswd -c ~/public_html/.htpasswd yourChosenUsername
echo "yourChosenUsername:$(openssl passwd -apr1)" > ~/public_html/.htpasswd
this only covers a username/password wall. if you need to restrict your personal page by host or ip address instead, email its-linux@binghamton.edu.
vhost sites don't get the self-service option above — restricting one still requires a small nginx
config snippet that our team writes and installs for you. a username/password wall (same mechanism
as above — you generate a .htpasswd file, we point the config at it) is definitely
supported — request it through the vhost restriction request form.
if you need something more specific, like restricting by host/ip address or combining the two, email
its-linux@binghamton.edu directly and describe what
you're trying to do — we'll confirm it's actually possible on this setup before promising anything,
rather than guessing.
htpasswd tool (same as
above) and place it somewhere under your own site directory, and you just give us the path. to be
clear about what that actually means: the hashed credential file does live on a server we operate,
and nginx reads it on every request to that path — we're not "storing" a plaintext password
anywhere, but we're also not going to pretend the file isn't sitting on infrastructure we control.
if that's not an acceptable tradeoff for what you're protecting, don't put it behind basic auth.