Https-everywhere: BU Library EZ Proxy redirect broken by HTTPS Everywhere

Created on 26 Apr 2019 · 10Comments · Source: EFForg/https-everywhere

Type: ruleset/website issue

Boston University provides library access to online materials for library members, after they provide their BU username and password. For example, a user could specify the following website for Wiley access:
http://ezproxy.bu.edu/login?url=http://onlinelibrary.wiley.com

When HTTPS Everywhere is disabled, everything works great. When it is enabled, the following error message is generated:

Licensing agreements for these databases require that access be extended
only to authorized users. Once you have been validated by this system, a
"cookie" is sent to your browser as an ongoing indication of your
authorization to access these databases. This cookie only needs to be set
once during login.

If you are using a firewall or network privacy program, you may need
reconfigure it to allow cookies to be set from this server.

As you access databases, they may also use cookies. Your ability to use
those databases may depend on whether or not you allow those cookies to be
set.

To login again, click here.

If instead the https versions are provided (as typed by the user) as follows, the extension does not break the website and everything works fine.
https://ezproxy.bu.edu/login?url=https://onlinelibrary.wiley.com

needs more info ruleset-bug

Source

kslays

Most helpful comment

Great!

For future reference, here's what I think happened:

EZproxy authenticates the user by setting a cookie but instead of using its own subdomain (ezproxy.bu.edu), it uses the parent domain, in this case bu.edu. HTTPS Everywhere was forcing the secure flag on these cookies:

https://github.com/EFForg/https-everywhere/blob/57a41c2edd22e4ee60c61691dba3c210085ee1e8/src/chrome/content/rules/BU.edu.xml#L51

With this setting, the cookies will only be sent when the target is reached via HTTPS. So unsurprisingly, it will cause issue when you visit http://ezproxy.bu.edu (via HTTP) because EZproxy won't see your cookie then.

Now, I'm not entirely sure why it doesn't work when you use https://ezproxy.bu.edu (via HTTPS) but it's difficult to debug this kind of issue without direct access to the problematic feature.

I think the easiest way to fix this on our side is to drop the securecookie instruction entirely for this domain.

Bisaloo on 29 Apr 2019

👍2

All 10 comments

Does this proxy open the page provided to it in <iframe>? That may be the problem if there is a <securecookie> tag in the ruleset. Also, can this be tested without being a library member?

pipboy96 on 26 Apr 2019

I don't know how it can be tested without being a library member. I'm not a developer so don't know how to help with these details. I was able to catch the page that loaded immediately after submitting my password, but before the redirect page loaded. Here is the code that Firefox "View Page Source" showed:

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <meta http-equiv="Refresh" content="0; URL=http://www.bu.edu/htbin/library/ezproxyLogin.pl?weblogin_tag=584d5364665172784844734141434c73625463;weblogin_authref=foo"> 
  <title>Boston University | Web Login | Redirect to Application</title>

  <!-- InstanceBegin name="header_template" -->

  <link rel="stylesheet" type="text/css" media="screen" href="https://weblogin.bu.edu/lib/css/style.css" />
  <script type='text/javascript' src='https://weblogin.bu.edu/lib/scripts/BUweblogin.js'></script>


  <!-- InstanceEnd name="header_template" -->

</head>

<body>
  <script type="text/javascript">
  <!--
  function setVisible(obj)
  {
    var item = document.getElementById(obj);
    item.style.visibility = 'visible';
  }

  setTimeout ( 'setVisible(\'wrapper\')', 5000 );
  //-->
  </script>
   <div id="wrapper" style="visibility: hidden">
    <div class="container">
      <h1>Web Login Successful</h1>
      <div class="error-box">
           <p class="notice">NOTICE: Weblogin complete; waiting for application.</p>
        <ul>
        <p><li> You have successfully authenticated to Web login and your
        browser has been redirected<br> to the application you
        requested.</p>
        <p><li>That application is currently in high demand; requests
        will be accepted in the order received.<br> Your browser will
        display the application page automatically as soon as it
        is available.</p>
        <p><li>If the application page does not appear within one minute,
        you may click
           <a href="http://www.bu.edu/htbin/library/ezproxyLogin.pl?weblogin_tag=584d5364665172784844734141434c73625463;weblogin_authref=foo">here</a><br> to retry
           your connection to the application server.</p>
        </ul>
   </div>
   </div>
   </div>
</body>
</html>

kslays on 27 Apr 2019

Also, I was wrong about the https versions (https://ezproxy.bu.edu/login?url=https://onlinelibrary.wiley.com) working. I now get the "Licensing agreements..." error message with the https address. I think I must not have cleared my cookies or re-enabled my extension properly before.

kslays on 27 Apr 2019

cc @J0WI @Bisaloo for suggestions.

pipboy96 on 27 Apr 2019

Do it only happen when you try to access Wiley journals or it is the same for other publishers?

Bisaloo on 28 Apr 2019

I think it's the same for any EZProxy target. I tried the following links from the library database list, and all resulted in the "Licensing agreements..." error:
http://ezproxy.bu.edu/login?qurl=http://webofknowledge.com%2fWOS
http://ezproxy.bu.edu/login?qurl=http://www.jstor.org%2faction%2fshowAdvancedSearch%3facc%3don%26wc%3don
http://ezproxy.bu.edu/login?qurl=http://search.proquest.com%2fhnpnewyorktimes%2fadvanced%2f%3faccountid%3d9676
http://ezproxy.bu.edu/login?qurl=http://www.nexisuni.com%2f
http://ezproxy.bu.edu/login?qurl=http://search.proquest.com%2fpqdtglobal%2fadvanced%3faccountid%3d9676
http://ezproxy.bu.edu/login?qurl=http://www.sciencedirect.com%2f

Also note that the error page title is "Cookie Required".

kslays on 28 Apr 2019

Is there a way to add an exception? Right now I am disabling HTTPS Everywhere entirely. Selecting "Disable HTTPS Everywhere on this site" for ezproxy.bu.edu did not solve the problem.

kslays on 28 Apr 2019

Thanks for the additional info!

You could try disabling the bu.edu ruleset by unchecking the box in front of Boston University (partial) when you visit https://www.bu.edu/. Then clear you cookie and try using EZproxy again.

Please let me know if that works. If so, we can add a permanent fix in our ruleset.

Bisaloo on 29 Apr 2019

Unchecking the checkbox Boston University (partial) for https://www.bu.edu/ worked on all the sites I had tested above.

EZProxy is widely used by many university libraries (Wikipedia article; parent company site). Keep an eye out for other websites of the form *proxy.{institution}.edu/login?qurl={URL}.

@Bisaloo and @pipboy96, thanks for fixing this. I appreciate it, and thanks also for helping improve HTTPS Everywhere.

kslays on 29 Apr 2019

🎉1

Great!

For future reference, here's what I think happened:

https://github.com/EFForg/https-everywhere/blob/57a41c2edd22e4ee60c61691dba3c210085ee1e8/src/chrome/content/rules/BU.edu.xml#L51

Now, I'm not entirely sure why it doesn't work when you use https://ezproxy.bu.edu (via HTTPS) but it's difficult to debug this kind of issue without direct access to the problematic feature.

I think the easiest way to fix this on our side is to drop the securecookie instruction entirely for this domain.

Bisaloo on 29 Apr 2019

👍2

Was this page helpful?

0 / 5 - 0 ratings