Access Problem Solving (digprob)
Proxy Primer
Please note that the public interface to Vera switched on August 20, 2008 from using our FileMaker Pro database as its back end to using SFX as its back end. As a result, the information below is now out of date. The proxy server is now talking to SFX, not FileMaker Pro, to manage URLs. We need to update this document to reflect that change, and will do so when we are able. [kam]
The Basics
The proxy server uses EZProxy software to enable and control appropriate access to licensed eresources from any location. In most cases MIT certificates will be required from off-campus but not while on-campus. In some cases certificates are required regardless of location, and in some cases further restrictions apply. The IP address of the proxy server is 18.51.1.222.
Our links to ejournals and databases in Vera are routed through the proxy server, allowing off-campus access, when the following conditions are met:
- ProxyUP=yes in the Calculated results box
the proxy server is up and operational (a global field: either all records show ProxyUp as yes, or all records show ProxyUP as no)- SystemOK=yes in the Calculated results box
the proxy server has been configured for the resource- Access_remote=yes (Remote Access OK=yes)
the license allows remote access- Access_control=IP Address
access is by IP address rather than password- Licensed=yes
The user is routed through the proxy server by way of an automatically constructed URL: the native URL entered into Vera is appended to the proxy server prefix string to create the URL result. The proxy prefix looks like this: http://libproxy.mit.edu:8000/login?url=
If the proxy server is down, the Systems Office can change all Vera records to ProxyUp=no, at which point the active URL will become the URL in the Native URL field, instead of the URL result field.
Get URLs also invoke the proxy server as long as the Get URL points to a URL which meets the conditions indicated above.
Remember: URLs in Barton do not send the user through the proxy server. For more information, see Common problems: Vera vs. Barton URLs.
How does a link in Vera send a user through the proxy server?
appears next to a resource in Vera when these four conditions are met:
- ProxyUP=yes
- SystemOK=yes (the proxy server is configured for the product)
- Access_remote=yes or Access_remote=USA only (the license allows remote access)
- Licensed=yes
The Go button pays no attention to Access_control; we don't care whether it's controlled by password or IP address, either way works for off-campus access. The system we use for passworded resources is smart enough to recognize whether the user is on or off-campus and do the right thing (similar to how our proxy server works).
Please note that any unlicensed resource will offer access from anywhere off-campus, but will not display a Go button, since it does not meet the conditions noted above -- it does not have the licensed field indicating "yes".
If no
ProxyUP=no (The proxy server is down, and systems has updated the Vera record)
This has never yet happened and those on the digprob list should have been informed if such an action was taken by the Systems Office.Response to User: Proxy server is down, unfortunately off-campus access is temporarily unavailable.
Response to User: the Go button should appear soon, and this will indicate that we have set up the remote access available for this new resource. (Followup with Ellen to be sure request has been made to Systems, or, in emergency, call systems to request set up, if you are sure all conditions are met.)
Response to User: Apologies, but off-campus access is not allowed by the information provider under our license.
Response to User: Unclear whether license allows off-campus access or not, forward problem to Ellen for license followup.
If a user cannot get in from off-campus even though the resource has a Go button:
If you can get in from your workstation on campus, the problem is usually with the user's certificates. The off-campus list is set up to receive questions from patrons that fall into this category, and the folks staffing the digprob list should refer such queries to off-campus.
If you cannot get in from your workstation on campus, the problem could be with the resource or with the proxy server. If you suspect it could be the proxy server, you can try accessing the resource using the native URL. If that works, the problem is with the proxy server. If that does not work, the problem is with the resource; consult the Problem solving primer.
If the proxy server is not working properly:
- Any resource that meets the conditions noted above will not work on campus or off campus through Vera, unless "ProxyUp" has been changed to "No".
- Access from the Barton URLs or Native URLs for the same resources will work.
- Resources that are password-accessed (Access_control=password) are not affected. For these titles, the URL is in the format http://libsys.mit.edu/dbs/linkit? and a linkit script is invoked when the URL is clicked on. This script prompts the user for MIT certificates before allowing them to go to the resource (or the page that gives them the needed login information).
Please note that in general, it is more likely that there is a problem with the user's certificates, the resource, or the licensing of the resource than that the proxy server is down. This has happened only once or twice since the proxy server was first brought up in the fall of 1999.
If you suspect that the proxy server is down, and it is after normal business hours, you can consult the emergency contact information for the systems office. For a suspected problem with the proxy server, the following steps should be tried: calling Systems at x3-1617. If no one answers, leave a message and then send email to fix-lib@mit.edu. If you are concerned about reaching someone immediately, you can also call the Head of Systems at her home phone number, which is included on the emergency contact page.
Special Considerations Related to Use of Firstsearch Outside the US:
We have an option to mark certain databases as "USA only" rather than simply "yes" or "no" for remote access. The reason for this choice is that one key license -- the one for Firstsearch -- includes a clause we were unable to get changed that says we have to prevent use from countries with US sanctions related to exports. Thus we can't allow users to access Firstsearch in countries embargoed or sanctioned by the US; since the list of sanctioned countries is constantly changing, we did not attempt to say WHICH countries, but to simplify with the 'USA only" message.
The L button displays this message to users: "Use is restricted to the United States only. Please honor this restriction by not using this database from any other country." This works by having certain linkit scripts assigned to category 2, "remote ok only if from USA". [the other categories for linkit scripts are no remote access, remote access anywhere, and certificates required anywhere.] Scripts in this 2nd category [currently only Firstsearch] check for a host name ending in .edu, .com, .net, .us, .org, .gov, or .mil, as well as the extensions for Japan, the United Kingdom, Switzerland, and Brazil -- exceptions made for MIT users (including some ChemE practice school sites) who need access from those nonsanctioned countries. If a user whose machine name does not end in one of these tries to access, a message appears that says: "your machine name (host name) does not appear to be in a US domain" and explains that they cannot have access.
If an MIT user is going to be outside the US in a country that is not sanctioned by the US, we can ask the systems office to alter the script to allow access from that country. (For example, we added Brazil in 6/04 since there was a user there for the summer who needed access.) To check whether a country is currently sanctioned, go to:
http://www.bea.com/framework.jsp?CNT=exportclass.htm&FP=/content/legal[This section on using First Search outside the United States last updated 040701 by Ellen Duranceau]
Special considerations about users at Lincoln Laboratory and Haystack
Even if a database or ejournal is fully established for remote access and shows a Go button, if the user is located at Lincoln Laboratory or Haystack observatory, he or she won't be able to use the database or ejournal if the access restrictions field indicates Haystack or Lincoln is excluded. (The user will see this as a message that says "licensed for MIT except Haystack [or Lincoln Laboratory]." An example of this is IEEE Xplore--it is not licensed for Haystack, so MIT folks at Haystack are being prevented from using it at Haystack even as remote users. The same staff members could use Xplore at home, however, with certificates.
Another way of saying this: Remote access won't work at Haystack or Lincoln if our license does not permit access at those locations. Remote access will work for MIT employees of Haystack or Lincoln who have certificates if they are at home or in buildings other than the excluded sites. This works as follows: if a user is coming from an MIT address, including Haystack, the proxy server sends that user right through to information provider's site, at which point the provider's server refuses access to any nonauthorized IP address, including the Haystack IP address. If the user is at home, the proxy server prompts the user for certificates, the user's home IP is accepted, and the user is passed on to the information provider's site appearing as if he/she is coming from an address beginning with 18, so is allowed in.
We do not publicize that fact or promote this particular kind of access because of the confusion and problems it could cause.