Followup

Check out the followup post.

Introduction

If you are a physicist, you must be reading American Physical Society’s journals. Some of the most famous journal are Reviews of Modern Physics (Rev. Mod. Phys.), Physical Review Letters (Phys. Rev. Lett.), Physical Review X (Phys. Rev. X), etc. Though most of the researcher’s have access to APS’s journal online on campus, you cannot access it at home due to IP limit.

APS provided a convenient tool: “Mobile Subscription” which allows you direct access to APS’s online journal without use a VPN from the university.

This not only speeds up your connection, but also could help you get rid of the clumsy VPN to campus.

If you setup a cron job that renew the “Mobile Subscription” every other week on campus, you would have continuous access to APS journals online at home as long as you are logged-in. However, more than a year ago, this “Mobile Subscription” or “APS go mobile” is semi broken and you have to log out and log back in every time you close your session. I have contacted APS through different ways and multiple times. They seem to not care or aware of the bug. Since I have used this feature extensively, it is worthwhile for me to fix by myself.

TLDR on fix

Potential work around for Safari: need to install Tampermonkey (costs 1.99$, not tested) and use UserScript. Fix for other browsers:

  1. log out and in on journals.aps.org
  2. Firefox: Tools -> Web Developer -> Web Console paste the userscript and hit enter.
  3. Chrome: View -> Developer -> JavaScript Console paste the userscript and hit enter.

How APS go mobile works

I have been using American Physical Society (APS)’s go mobile subscription for more than 6 years. The idea is the following, if you log in your personal account at your institute with APS subscription, go to your account and mobile subscription and you can have 2 weeks (2 months now due to COVID19) of personal subscription to the APS journals. Supposedly, if you are logged in and at home, you can browse the APS website as if you are in the campus.

What does the bug look like

APS, however, introduced a bug a year ago. It requires you (at least for me) to logout your account and log back in to be able to download PDFs. You should be aware that that aps.org and journals.aps.org use two different accounts. Here, we are concerned with journals.aps.org. You have to do this logout and in again and again every time you close your browser (technically, it is decided by your browser, so YMMV).

Bug description

APS uses a series of cookies (stored locally with a lifetime specified by APS server). APS uses different cookies to check if you are logged in (likely a cookie named “apsjournals.session”) and if you are authorized to download PDFs (cookie named auth_token). During a website restructure last year, APS introduced a bug that let the “auth_token” expire after the “session”. Here “session” could mean different things in different browser. It could means the closure of webpage, the closure of browser,… You could even compile a browser that make it last one second or forever. For me, one I close all the APS webpages, I do not have that cookie anymore. A more sane choice of the lifetime would be at least the length the “go-mobile” subscription or sync with the login status (which expires after one month of inactivity) or least a few weeks.

Solutions on the client side

To circumvent this bug, we need to modify the expiration date of the cookie. Even though the server force your cookie in the browser to expire very fast, the server is still keeping track of your authorization correctly. This means that if we could prevent this cookie from expiring, we are good to go.

The fix would be to keep the cookie even though the server explicitly tell the browser to forget it fast. Unfortunately, what we are allowed to do is again dependent on the browser. For example, since the latest version (version 13 which comes with macOS Catalina), due to “security” concerns, Safari only allow the client to modify the cookie lifetime up to 7 days, which means that you need to reassign the cookie every week. For Firefox/Chrome, it is a rather simple fix.

Partial Solution on Safari

If you insist on using Safari, you could follow the instructions below:

  • If you don’t see the Develop menu on the top menu bar, click on Safari ->Preferences, go to Advanced tab, check “Show Develop menu in menu bar”
  • Go to journal.aps.org, log out and log back in.
  • Go to “Develop ->Show Web Inspector”, click on the “Storage” tab.

  • As you can see, right now the session expires immediately after the session (you could double check by quit and reopen safari and check you cookies again).

  • copy and paste the following javascript (snippt from stackoverflow) on the console located at the very bottom of Safari and click enter (you could go to Develop -> Show JavaScript Console to debug webpages).

    userscript 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

var days=3650;
function getCookie(cname) {
    var name = cname + "=",
        ca = document.cookie.split(';'),
        i,
        c,
        ca_length = ca.length;
    for (i = 0; i < ca_length; i += 1) {
        c = ca[i];
        while (c.charAt(0) === ' ') {
            c = c.substring(1);
        }
        if (c.indexOf(name) !== -1) {
            return c.substring(name.length, c.length);
        }
    }
    return "";
}

function setCookie(variable, value, expires_days) {
    var d = new Date();
    d = new Date(d.getTime() + 1000 * 24 * 60 * 60 * expires_days);
    document.cookie = variable + '=' + value + '; expires=' + d.toGMTString() + '; path=/; SameSite=Lax;';
}
var oldcookie=getCookie("auth_token");
setCookie("auth_token",oldcookie,days)
  • You are done for one week. Though we put 10 years, security restrictions from Safari restrict the maximum to a week. You can double check if you are successful by close and reopen journals.aps.org and recheck the cookie to see if it expires after one week.
  • You are welcomed to visit this page every week to refresh your cookie.

Apparently, this is super inconvenient, I would rather use other ways such as use VPN, proxy, etc.

I am rich and insist on Safari

If you are rich to afford Tampermonkey from the App Store which costs 1.99$ you could try to this userscript so that each time you visit the page, the cookie refreshes its expiry time. The downside is that it adds a bit more cpu time and the userscript is only tested in Firefox.

Solution on Firefox

Firefox comes to rescue now. If you use firefox, you could log out and log back in journals.aps.org and do one of the following:

  1. Download Cookie editor and edit the cookie “auth_token” to expire in a later time.
  2. Tools -> Web Developer -> Storage Inspector and edit the cookie to a later time (double click the expire time of “auth_token” cookie).
  3. run the above script by going to Console tab under Tools-> Web Developer.

Firefox is much more developer and advanced user friendly now. If you are an advanced user, it is time to reconsider if you still want to use Safari again.

Disclaimer

This is based on my personal test on Safari/Firefox/Chrome. Since I haven’t heard any colleague using “go mobile”, I am not aware if any of my colleges encounter the same bug. I tried to report this bug multiple times without any feedback but a simple acknowledgement. It could be that the “go mobile” feature is not used by many people. Interestingly, APS actually promotes the usage of “go mobile” during COVID. But if you are experiencing the same bug which prevented you from using this feature. You may find the bug fix helpful. Or, if you are from APS technical team, I hope you can fix this bug on the server side once and for all.