Ezproxy license

If you are currently using EZproxy V6. If it is able to validate the key, you will see a new expiration date 3 months from validation in your messages. You can ignore these expiration dates as your WSKey will expire a year from your subscription's start date or you can upgrade to V6.

For more details see Known issues. At this point, several things could happen: EZproxy will successfully connect with the WSKey server, check the key for validation, and receive a confirmation that the key is connected with a current EZproxy subscription.

EZproxy will successfully connect with the WSKey server, check the key for validation, and receive a message that the key has expired.

EZproxy will not be able to connect to the WSKey server due to firewall or other network security issues and will not be able to validate or invalidate the WSKey. WSKey alerts V6. EZproxy was last able to validate your WSKey 90 days before the date recorded in these alerts. These restrictions in our proxy server prevent excessive automated downloading or other spoof mechanisms and are necessary because of our license agreement with vendors.

When you see this message, it means you have exceeded the downloading limit allowance of MB per 2 hours. Generally, you can opt to wait for about 2 hours for your connection to be restored.

Partitioning run-time processing from configure-time processing is a very good thing. Except by writing to the license file, this breaks the partitioning run-time from configure-time. Look at the model that most other software uses:. Some software will chroot to an empty directory to raise the "you must be this tall" bar for compromising the system at this stage.

By making it so that the license key file is writable by the RunAS user, a security weakness is introduced where an attacker who finds a way to the RunAS user account can setup a denial of service attack via the license file: delete it, corrupt it, fill up the disk space that holds the file and there are several nasty ways to do that under the radar , etc.

There are probably as many different ways to manage an EZproxy server as there are EZproxy servers. Some of these may involve giving out access to the RunAS user for various reasons. Your site might have administrators install the software, then hand it over to an electronic services librarian who configures and maintains it.

Or manages user authentication files. Or updates the database definitions. The point is that is is not hard to imagine a scenario where users might share access to the RunAS user account, or are put into the same group as EZproxy and have write access to the license file, either intentionally or by oversight.

Now, combine this with the fact that the license file has to be writable by the RunAS user, the overall system is made less secure.

On the innocent side, users make mistakes and accidents happen. Ever do a "rm -rf. You'll hopefully only do that once, and learn a painful enough lesson that you won't ever do it again. On the nefarious side, ever have a staff member leave under less than optimal circumstances?

One simple change to the license file, and your proxy is now a ticking logic bomb. Either way, an action that is normally benign -- a proxy software or server restart -- will now turn into a major problem. How long will it take you to figure out what the problem is, find the license code, and fix it? Murphy says this will happen after support hours before an extended holiday, all of your backup tapes were stored "on top of the new cabinet" which turns out to be a transformer , and the only person who knows the license code will be on a pilgrimage to Motuo County.