New Subject Crashes Site

[VeryKross]

Describe the bug I'm a new NS user and have the site setup and running well with version 14.2.6. I followed the instructions for creating a new Subject so that I could add a "read only" access key and otherwise lock the site down to only users with a valid token. However, after filling in the Edit Subject dialog and clicking Save, the dialog simply closes and the new subject doesn't show up in the list and no token is presented; it acts more like I've clicked Cancel.

Thinking it might just be a refresh issue, I restated the web app and it failed to start, instead showing an error related to authentication.

To get the website back up, I deleted and recreated the "test" database and restarted the website so it would recreate its collections and I was back in business.

I then retried the above steps, getting the same result when saving the subject. I then looked into the auth_subjects collection in the database and saw an entry for the subject I had just created, even though it did not display on the website admin page. I restarted the website and once again received the database error, prompting me to once more delete/create the test database in order to get back running.

To Reproduce Steps to reproduce the behavior:

1. Go to 'Admin Tools' on a newly installed website (there are no existing subjects)
2. Click on 'Add new Subject'
3. Fill in the Name and Roles fields (e.g. "Site Reader" and "readable" respectively)
4. Click on 'Save'
5. Note that the list of subjects under "Subjects - People, Devices, etc" does not update and still reports "Database contains 0 subjects"
6. Restart the website
7. See the startup database error message

Expected behavior I expect that when I save the new subject, I'll see it reflected in the Admin Tools along with the newly assigned token value

Screenshots If applicable, add screenshots to help explain your problem.

Your setup information

• Nightscout version 14.2.6
• Website is installed on Azure App Service via the Nightscout supplied Docker image on DockerHub
• Database is Mongodb via Azure CosmosDB
• Tested with latest Chrome browser

Additional context Followed instructions posted to YT by Scott Hanselman for installation and the site otherwise appears to work correctly.

[snickerdoodleparent]

I updated Nightscout on Heroku from v 14.2.5 to 14.2.6 and I agree I see an issue creating a new subject role. In my case a new subject is created (maybe because I upgraded and didn't start new?) along with a token, however that token does not work -- unless the subject is assigned admin role. In the MongoDB (on Atlas) I see a new subject (person) is created but the accessToken is not stored, not for a careportal, read or admin roles. The database also does not store the admin token, so I am baffled as to why the admin user created works.

[andymorton]

I have just had the same issue. I created the users as noted above, but they didnt appear. Once I restarted the web app, everything broke. I got round it by deleting the auth_subjects collection in the cosmos db browser, then recreating the collection.

[vanelsberg]

Seeing the same issue as @andymorton describes: I think the problem is in the collection names containing underscore characters?

[MarcinJuraszek]

It's not the underscores. It's indexing. Looks like CosmosDB does not index everything by default? Manually adding name as index to auth_subjects collection seems to do the trick:

I'm pretty sure if you're trying to use custom roles, you'll have to do the same in the auth_roles collection.

[sulkaharo]

FWIW Nightscout doesn't "officially" support CosmosDB and hasn't been tested with it by anyone in the dev team, so what you get is what you get if using Cosmos. If someone wants to PR a code change that creates the indexes with Cosmos, we can look at merging it, but as is nobody who usually contributes code to NS is likely to do anything about this as nobody in the team uses Cosmos.

[vanelsberg]

Would be great when this could be fixed. Deploying Nighscout to Azure WebApps is really nice and super clean & easy. And it is absolutely free!

[vanelsberg]

It's indexing.

Thanks. Confirming. Manually adding "name" indexes solved the problem of not being able to edit roles and subject. Expect this also prevents possible crashing on a newly created database?

[VeryKross]

What's interesting is that this Collection (auth_subjects) isn't created by default with the database so it must be created dynamically when the first Subject is added. By default [via the Azure portal], new Collections are setup with all fields being automatically indexed so it seems that when this [and other?] collections are being created dynamically, this automatic indexing property isn't being set.

[MarcinJuraszek]

Yeah, that's interesting. I'm curious if adding it to the list of collections created by default would solve this. Let me check it, as that would be a really easy fix.

[MarcinJuraszek]

I think this can now be closed, as @sulkaharo merged my PR to ensure indexes on Roles and Subjects collection as set up as part of boot.

[VeryKross]

Fantastic news! Great reason to update my installation! This is the main reason I was wanting to lock it down originally - a little monitoring gadget I put out: https://github.com/VeryKross/BGBuddy