-
Notifications
You must be signed in to change notification settings - Fork 72.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Subject Crashes Site #7617
Comments
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. |
I have just had the same issue. I created the users as noted above, but they didnt appear. |
Seeing the same issue as @andymorton describes: |
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. |
Would be great when this could be fixed. |
Thanks. Confirming. |
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. |
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. |
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. |
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 |
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:
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
Additional context
Followed instructions posted to YT by Scott Hanselman for installation and the site otherwise appears to work correctly.
The text was updated successfully, but these errors were encountered: