Stretch_web_interface installing and using: login unauthorized

I am trying to test the stretch_web_interface on the robot. I downloaded the repo and started following the instructions on the Readme.md

At first I was having some messages related to mongodb when I tried to run [ sudo ./web_interface_installation.sh ]

I think I finally got that sorted once I observed the following output:
Look at the following output to make sure the mongodb service is working.
● (this was a green dot) mongodb.service - An object/document-oriented database
Loaded: loaded (/lib/systemd/system/mongodb.service; enabled; vendor preset: en
Active: active (running) since Thu 2020-08-13 13:49:15 PDT; 3s ago
Docs: man:mongod(1)
Main PID: 32345 (mongod)
Tasks: 23 (limit: 4915)
CGroup: /system.slice/mongodb.service
└─32345 /usr/bin/mongod --unixSocketPrefix=/run/mongodb --config /etc/m

Aug 13 13:49:15 stretch-re1-1008 systemd[1]: Started An object/document-oriented d

I followed the use instruction to run the launch file first and then the start_desktop_dev_env.sh second.

When I open the browser and try to login is when I get stuck. The login information provided in the Readme.md outputs “Unauthorized” after pressing the login button. I tried registering a second robot account with a different password and when I use that I just get bounced back to the home page with no output of camera as is to be expected.

This is the output I see in the terminal when I try to login using the ‘r1’ information, press back after the “Unauthorized” page appears, and try to login with the newly created user:

GET /login 200 18.799 ms - 1621
GET /stylesheets/style.css 200 0.430 ms - 777
POST /login 401 1.814 ms - -
GET /login 200 16.582 ms - 1621
GET /stylesheets/style.css 200 0.315 ms - 777
POST /login 302 252.368 ms - 46
GET / 200 16.152 ms - 1200
GET /stylesheets/style.css 200 0.503 ms - 777

Hi @csemecu,

Thank you for writing! @bshah is beginning to look into this, and I should be able to set aside some time this evening and on the weekend. We’re happy you’re trying out the web interface!

Best wishes,
Charlie

Charlie Kemp, PhD
co-founder & CTO
Hello Robot Inc.
https://charliekemp.com

Hi @csemecu, welcome to the forum! It’s likely that the login information for ‘r1’ wasn’t populated into the Mongo database. In the web_interface_installation.sh script, the following lines populate the login information into mongo:

# INITIAL MONGODB DATABASE
echo ""
echo "Load developer credential database for robots and operators into MongoDB."
echo "WARNING: THESE CREDENTIALS ARE WIDELY KNOWN AND SHOULD NOT BE USED OUTSIDE OF SECURE INTERNAL TESTING."
cd ~/catkin_ws/src/stretch_web_interface/
mongorestore -d node-auth ./mongodb/test-users-db-20171021/node-auth/
echo "Done."

Would you run the mongorestore command and post the output here? Hopefully, the login should work after this information is added to the database. In case this doesn’t work, it would also be useful to have the output of the ./start_desktop_dev_env.sh command.

By the way, for anyone who is interested in the stretch_web_interface repo, I recommend using MondoDB-Compass, a GUI to see and manipulate the contents of Mongo databases. I replicated the unauthorized issue described here using it.

I added a commit to the repo that installs MongoDB-Compass as part of the web_interface_installation.sh script. Running the script again will install the tool, then you can launch it from the command line using mongodb-compass.

Here’s how I replicated the unauthorized issue. My working installation had the following databases in the gui:

Removing the node-auth database and running the login steps gave me the same unauthorized screen:

After running mongorestore command described above, the node-auth database reappears and login works correctly once more.

1 Like

Thank you @bshah and @hello-ck!

I updated the repo with your latest commit and checked that the installation.sh displayed all the outputs, including the populating the database.

After that I have been able to run the script on the robot, and access as an operator from a different computer.

My next step (in case anyone else has more recommendations or is doing something similar) is to figure out the best way to access the robot remote teleoperation as operator from a device that is not in the same network as the robot. Currently we are using localhost in the robot’s machine and using the IP given with ifconfig to access as the operator. Normally with a robot in a local network (wifi), that IP is not accessible to anyone off that network.

I will keep updating if new issues arise or if new ideas for cool teleoperation come up! Really nice work!

Update: here is a video with screen recording of the web interface and a 3rd person view https://photos.app.goo.gl/wjoBoms9qNEnfhi56

1 Like