OIT Tech 32px

Restricting Access to Your Secure Web Pages

You are able to restrict access to your secure Web pages, permitting only those people whom you authorize to see your pages.

This feature is now activated on the people2 server; there are no known problems; but please do confirm that the restrictions you intend are working correctly, and report any problems you encounter.


How to Restrict Access

In order to restrict access to your Web pages, you must:

  1. Until the 2015 cutover, follow the instructions at step 4 in the outline procedure for Transferring Files, to be sure that you are working in the "secure" folder, instead of the "public" folder.

  2. Then scroll down to and open the folder whose name is your Ohio ID.

  3. For any new resources, or older resources that you intend to preserve online after the cutover, scroll down to and open your "restricted" folder. Upload the files whose access you wish to restrict into that folder, along with the "ht.access" file (as described below) that establishes those restrictions, using your normal uploading procedures.

  4. You will link to those pages with URLs such as:


    The "s" before the colon is required in order for the secure server to be used.


Default Restrictions

On people2, as was the case on OAK, the default restrictions are to permit everyone with an Ohio ID to see your pages after they have logged in. This includes roughly 225,000 people, in the following categories:

  • current employees

  • retirees

  • some other former employees

  • current students (full-time and part-time, undergraduate, graduate, and medical, on the Athens campus, the regional campuses, and distance learning)

  • admitted students

  • applicants for admission who have formally started the application process

  • former students, including alumni, who were enrolled since Fall, 1994, when the original OAK all-student e-mail system began service

  • some alumni whose last enrollment preceded Fall, 1994

  • a variety of people with "guest" status (e.g., research collaborators, vendor staff who are under contract to assist departments maintaining web sites, etc.).

Although the default restriction permits a large group to see your pages, it does prevent your secure pages from being included in any public search engine, and because the page is served securely, no one else can eavesdrop on the network traffic to see the content.


Custom Restrictions

You can override the default restrictions by specifying your own. On OAK, restrictions were established using files named ".htaccess"; on people2, the corresponding files are named "ht.access"; the contents have the same meaning, so you may well be able simply to rename the file you already have and upload it to people2, but we do urge that you check carefully that the restrictions you intend are in fact functioning correctly.


Because of differences between the operating systems of OAK and people2, there may well be file format issues, so that in addition to re-naming your old ".htaccess" files, you may have to re-save them, adjusting the format. This text will be updated with details, based on problems reported by users and on our experiments (as of October 25, 2012, we have received zero such reports).

In the meantime, if you encounter any problems, even if you figure out how to resolve them yourself, please report them to us, by sending e-mail to servicedesk@ohio.edu, so that we can warn others.

As mentioned, in addition to your web pages, you must also upload a text file named, "ht.access," whose contents establish the restrictions on who can see your pages, unless you are satisfied with the default restrictions. There are three ways you can specify who has access:

  • everyone who has an Ohio ID and password (this is the default, which will be in effect if you include no "ht.access" file);

  • those who are on a list of specific Ohio IDs; or

  • anyone who is in an "Active Directory group" maintained by OIT (e.g., the group of people who are authorized to update a specific Front Door subsite). It is possible for an AD group to have as one of its members another AD group; that works for authoring access, but does not work for browsing access control at this time.

If you use more than one of the three, the server will combine them with a logical "OR": a person need only match any one (or more) of the specifications to get access.

If you want to grant access to a large group of people, so large (or so volatile) that maintaining the list manually would be a significant burden, please contact us by e-mail to servicedesk@ohio.edu, and describe the group you are thinking of. Perhaps OIT will already have that group in place, or be planning to maintain it for other uses, either manually or automatically.

The server will ignore any lines in your ht.access file that start with pound signs ("#"), which permits you to leave comments in the file that will jog your memory or assist anyone else who works with you on your pages. Generic comment lines should be removed from the ht.access files that you use, in order to reduce server overhead parsing through them: the entire ht.access file is read and parsed for each access to any resource in the secure subsite and all contained sub-subsites. That said, we do urge that you keep comment lines that will be helpful to you or your assistant!

You may want to copy and paste the text below, or you may just type in the parts you want to use. Caution:   the action lines in your ht.access file (the ones that don't start with "#") are case-sensitive (e.g., "Require" works but "require" does not), even though people2's operating system is case-blind for file and folder names.

It is safe to place the ht.access file in the same folder on the server with your published documents, because the web server is configured to refuse to serve any file whose name ends with ".access".

Everyone who attempts to see a page in the secure subsite will be challenged for their Ohio ID and password. They will then see the page if, and only if, they meet one (or more) of the criteria specified by un-commented lines in the ht.access file.


Model ht.access File


# This is a model ht.access file

# To permit everyone with author access to a particular Front Door subsite to see
# the pages, uncomment and unwrap the following line and replace the
# "subsite" (highlighted) inside the cn value with the actual name of the
# subsite, in all-lowercase letters:
# Require ldap-group cn=OIT-WEBSVC-subsite-admin,ou=WEBSVC,ou=OIT-AIS,ou=OIT,ou=Ohio,dc=ohio,dc=edu


# To permit everyone with a valid Ohio ID and password to view the pages
# in this subsite, and no one else to see them, uncomment the following line:
# Require valid-user


# To permit specific individuals, and no one else, to view the pages
# in this subsite, uncomment and include one or more lines of the form:
# Require ldap-user user1 user2 user3

# To permit only a specific individual to see a particular file, uncomment and
# include blocks of the following sort:
# <Files "filename.html">
#     Require ldap-user user1
# </Files>
# the "ldap-" may be omitted;
# replace each "userN" above with the appropriate Ohio ID;
# multiple users and multiple lines of this form are combined with a logical OR