Remove XSRF workaround & open WebCAT in new tab

[MagicShoebox]

This article describes how to properly send the XSRF token stored in the cookie with requests to Jupyter's REST API.

This removes the need to disable XSRF protection on the entire notebook server, so I've removed the script and associated documentation.

Additionally, there were authentication issues using WebCAT in an iframe, so instead this simply opens the link in a new tab.

There's also a commit to delete the extraneous HTML element that tries to load a non-existent CSS file.

[cashaffer]

I would be feeling more confident if I knew who you were.

[MagicShoebox]

Hi, thanks for the response.
I've sent you an email with more detail, by way of introduction.

As for the pull request itself, I am attempting to address 3 separate issues. (I possibly should have opened 3 separate PRs.)
Feedback welcome!

1. When the frontend part of the extension (main.js) is loaded, it adds a reference to a non-existent main.css stylesheet, resulting in a doomed request (results in 404) while loading the notebook. This doesn't really harm anything besides cluttering up the server and browser logs; I was just doing a bit of housekeeping. In my cursory browsing of the repository, no such file has ever existed. My assumption is that it was leftover from a template or tutorial first used to create the extension.

2. While reviewing the installation instructions, the part about modifying the notebook configuration jumped out at me. In attempting to learn more about the issue, I came across the article linked in the first comment. The Jupyter notebook server uses a REST API, which is protected from XSRF by a token. I believe (but did not confirm) that the installation instructions disable the protection entirely. Not only does this make users of the plugin less secure, but this step complicates the installation to boot. My changes modify main.js to use the XSRF token as documented in the article, allowing XSRF protection to remain enabled. I also removed the steps disabling XSRF protection from the instructions, as they were no longer necessary or desired.

3. The most complicated issue, by far, is the actual act of submission to WebCAT. In short, the notebook server isn't authenticated with WebCAT, so it can't submit the assignment directly. Instead, it attempts to use an iframe, relying on the browser to authenticate. Unfortunately, this doesn't seem to be working for several students. I have some theories (the SameSite=Lax change), but my knowledge in this area is weak. My workaround is to simply open a new tab/window to complete the submission, rather than relying on an iframe. I'm sure there's a better fix, but I would need to learn more about iframes, cookies, CAS, and WebCAT before I knew what it was.

[ranjiGT]

How can I modify the Web-CAT extension to work for JupyterHub?