...
- Application based authorization
- Public/Private sites
- .htaccess vs. Directory vs. Location Restrictions
- Suggested layout for Public site
- Suggested layout for Restricted site
- Satisfy any/all
1. Application based authorization
...
In this example this also allows you to have "site1.cornell.edu that is "public" and "site2.cornell.edu" that is restricted like below. Be careful not to place a top-level ".htaccess" file.
...
5. Suggested layout for a restricted site
If all your access is going to require authentication it is still a best practice to utilize application based authorization, but you have further options if you want to restrict all your sites. If you want to restrict all your sites you can place a top-level ".htaccess" file in your htdocs directory.
...
Unlike in the previous example both site1/site2 will inherit the permission that is set in the top-level restricted directory.
6. Satsify any/all
If you need to open access to the top-level of your SSL site, but want to secure sub-directories in your site you need to do a careful mixture of "satisfy any" and "satisfy all".
To open up access at the top:
| No Format |
|---|
htdocs/site1/.htaccess:
satisfy any
|
to protect a sub directory:
| No Format |
|---|
htdocs/site1/secure/.htaccess:
satisfy all
require netid emc256
|
Note that if you do not add "satisfy all" the "secure" directory will not be protectedYou can only further restrict sub-directories using CU WebAuth. So it is not possible to limit the entire site to "staff" and then try and make a sub-directory accessible by "students"!