Zotero triggering usagelimits in ezproxy

Hello, my name is Paul Sitko and I work at OCLC on the EZProxy implementation team. We've recently received an email from an EZProxy customer who has the UsageLimit directive set to 100MB in their EZProxy installation. They say they have noticed that users using Zotero are triggering the usagelimit when they shouldn't, with a much greater frequency than normal users.

I've recommended that they turn off the automatic remembering of proxied resources, but I'm wondering if there is something else going on behind the scenes that Zotero is doing that might be triggering these usagelimits. Is Zotero doing link-checking or anything else that may be generating traffic behind the scenes that is causing the triggering of these usage limits? Is anyone else experiencing these problems?
  • edited February 19, 2013
    The only situation where Zotero would generate HTTP traffic without being prompted to do so by the user is on a webpage with an unAPI endpoint, and in that case the amount of traffic generated would usually be a couple kilobytes per page.

    Zotero provides facilities for users to save an entire page of references at a time with attached PDFs. If the PDFs are large, this could easily exceed a 100 MB usage limit.
  • Do you know the time period on the UsageLimit? Along with Simon, my best guess here would be Zotero's (default) automatic PDF downloads combined with people using Zotero to download pages of results at a time for later (local) evaluation. That's a type of usage we've never recommended but have had a decent number of people report doing (sometimes in the context of getting banned from a particular site).

    If this is happen during more standard usage—saving a few results at a time—that'd be more concerning.
  • I'm trying to get the customer to provide us with their configuration and log files. I just wanted to know if there was anything EZProxy was doing that might cause this. I also think that a 100MB limit is incredibly small, given that a user could blow through this limit by downloading a few pdf files. I've encouraged the user to increase their limit. They insist that this usagelimit breaching behavior is limited to their zotero users, though, so I wanted to know if there was anything going on on the zotero side that I should know about. There doesn't appear to be however.

    I'm concerned that the Zotero automatic proxying may be coming into play here, as zotero will proxy items that don't necessarily need to be proxied if they have accessed them before through ezproxy and their config file is set up to proxy some free resources. That's why I've recommended that their users turn off automatic proxying in zotero. I had a related problem with automatic proxying when I was using ezproxy servers at two different institutions as a student and would find myself going through one ezproxy server, when my intent was to go through another.

    The automatic proxying behavior is somewhat problematic with EZProxy, and I don't see any real way around that, although I do see the benefit of it. Perhaps it's problematic enough that it should be turned off rather than on by default in a Zotero installation?

    Thanks for all your input.
  • I've gotten more input from the customer, including a look at their log files. Apparently, whenever someone connects to any of their proxied databases using a zotero-enabled firefox browser, it's generating a ton of 302 redirects. It's like they're stuck in a redirect loop. And what's triggering the EZProxy usage limit is not the amount of data transferred, but the number of page hits because of the redirect loop. Has anyone seen behavior similar to this before? It doesn't occur with non-zotero users.
  • Sorry for dropping this. Is their EZProxy set up for proxy by port? If so, https://forums.zotero.org/discussion/28505/ might be relevant. Otherwise, it might help to have an idea of what the pattern of requests looks like. If you'd rather not post it publicly, you can send it to support@zotero.org.
Sign In or Register to comment.