Appellate (?): httpOnly cookie flag disables extension

[mlissner]

Somehow the httpOnly flag is getting set on the PacerSession cookie. When this happens, the extension can't get its value, and thinks that the user is not logged in. In the console, the extension says:

RECAP: Taking no actions because not logged in:

This is too bad. It means that once the httpOnly flag is set, RECAP is disabled.

I got this message today while looking at appellate docket reports, and can share that the only domains I've been to today are:

pacer.gov

and:

ecf.cafc.uscourts.gov

I did mess around with the settings in the "Manage my profile" part of pacer.gov.

I went and tried to reproduce this, but I couldn't get the httpOnly flag to be set again.

In any case, I'm not sure it matters how the flag is getting set, since this change in functionality means we can't check the cookie's value any more (unless we intercept network traffic?).

That might be a solution, but I'm curious why we even bother. Maybe we don't need to check if folks are at PACER, or maybe there's a better way to do so (by URL, perhaps?).

[ERosendo]

I checked the methods that are using this cookie and I've found that we use it in the following cases:

• Identify the login page from PACER and avoid using the appellateDelegate or the contentDelegate class (like here)

• Avoid executing methods if the user is not logged in ( like in the handleDocketQueryUrl method from the contentDelegate class )

I think we can use another approach in the first case. We can create a helper method that identifies the login page using the URL and remove the check that uses the cookie. This new helper method could be something like this:

// Returns true if the given URL is for the login page.
const isLoginPage = function (url) {
  return PACER.getCourtFromUrl(url) === 'login'
}

I've been testing the extension in a few appellate courts (mostly the 8th, 9th, and 11th circuits) and PACER always takes me to the login page if I try to load a resource but I'm not logged in, so It seems like PACER is also checking the cookie and redirecting users if they need to use the login page. I'm not sure if this happens in all circuits but we could use this behavior to remove the second case listed above (the extension won't execute any JS until the DOM is complete).

[mlissner]

So historically, login wasn't centralized like it is now, and every district and appellate court had its own login page. That page would be shown even if you were at a URL for dockets, so it was confusing to figure out questions like, "Did this URL for a docket load a docket or a login page?"

These days, all courts have finally upgraded to NextGen, something they had been working on for like a century. That means that they all use the same sign on page, thank goodness, and the URLs are redirected to ones you can detect!

Thus, this sounds great and reasonable, whereas not long ago, it was a pain:

We can create a helper method that identifies the login page using the URL and remove the check that uses the cookie

And I think the second case is no longer important either because all the uses I saw where we check for the cookie it wouldn't matter if the code ran even if the cookie were missing.

That said, I think we have an open question as we work here. Do we take the cautious approach and code like this:

if !pacer_cookie and !login_page:

Or like this:

if !login_page

I think we can get away with the latter, but it's the riskier way to go.

[ERosendo]

These days, all courts have finally upgraded to NextGen, something they had been working on for like a century. That means that they all use the same sign on page, thank goodness, and the URLs are redirected to ones you can detect!

This is great!.

I also think we can use only the login_page check and avoid relying on the PACER cookie.