Problem with sidebar and login (from within it).

[tadawson]

I am with Michigan Technological University, and am working to deploy the current JS based NB to replace a legacy "v1" installation that we found here on campus under RedHat6 (which we need to remove from our environment).

In any case, I pulled the new NB code from Git back in December, and followed all steps to install Postgres, Node 16.9, etc. and all looked good - the software came up, we could add content, etc. Not being familiar with NB, I did not notice the absence of the sidebar until the professor using NB noted it. Upon investigation of old bugs and some debugging, I found that the issue there appeared to be that "bundle.js" is being called by nb_viewer.html from the path "client/bundle.js" and as the repo is cloned, there is no such directory. (I looked at the current Git source, and noted in the file "deploy.md" that you need to create the "client" dir and copy bundle.js to it, which I have done. (Is this correct? And does anything else need to be in client? That readme is very vague, and a lot of what is written does not work . . .).

So, the current problem: bundle.js now loads, and gives a login prompt in the sidebar (which is odd, since the user just logged into NB moments ago . . ) but while you can enter login/pass, it does nothing. Looking at a web debugger shows that bundle.js is trying to load a number of additional items from http://localhost:8080, which clearly does not contain any content or even a webserver for that matter, an is failing with "NS_ERROR_CONNECTION_REFUSED". (Screen captures of both the network and console portions of the web dev tools from the browser attached - same result in multiple browsers. The last few lines result from clicking the "login" button. I I attempted to edit the "http://localhost:8080" in bundle.js to our local URL, but that fails with security warnings about wanting to pull something via http and not https, but the config as distributed does not listen on the http port, and, as per the README.md file, I have http redirected to port 443 via nginx . . .

I can be reached at tadawson@mtu.edu (using my personal github login to expedite getting this submitted).

Hopefully, this is just a config error that I missed (or that didn't make the docs).

Oh, and is it possible to get an expanded (IE human readable) verseion of "@" and "bundle.js"? It's almost impossible to work in those files . . .

Thanks,

• TIm

[tadawson]

Determined issue was due to needing to do a rebuild of nbclient with local addresses. Got caught in the lack of mention in the NB README that nbclient was a dependency, and that the "bundle.js" for nbclient that pulls is not suitable.

[karger]

I don't understand your point about "bundle.js for nbclient that pulls is not suitable". Are you able to submit a pull request with an updated README so other don't face the same issue?

[tadawson]

Sorry, I shoud clarify. When you retrieve tne nb git repo (I used clone in this case, although the 2022.12 tarball is the same), there is a bundle.js in the public directory, and it is hard wired to localhost based on the environment set when webpack was run for it. Unfortunately, nb_client.html loads bundle.js from public/client/js, so the first issue was a 404 error when trying to load bundle.js, and then once that was corrected (moving the bundle.js in the nb git tree to client/js), bundle.js attempts to determine the logged in user via localhost, which cannot work from a remote browser. Only after I also realized that I needed nbclient as well, and editied it to my addresses, rebuilt it, and installed it in the nb public/client/js location could I get this to work. Granted, I am not with MIT, but total lack of reference to needing the nbclient package in the nb README didn't help, and the failure of the client to derive it's environment from the nb environment (from whence it loads) produced far more frustration that likely should have been encountered (although I am a lot more familiar with your code than when I began). Other references to MIT sites scattered throughout the project does not make deployment elsewhere easy, but that I can understand, since this was not written for use elsewhere. A top level set of defines which would drive everything, as well as inclusion of all required components in one git tree sure would make deployment easier!

[tadawson]

Oh, and I can certainly submit updates to the README detailing what I needed to do.