Repository navigation
Role elevation failure message #1107
Description
- Not sure how to fix this yet
- Some possible fixes here at http://stackoverflow.com/questions/24430220/e11000-duplicate-key-error-index-in-mongodb-mongoose ... however we won't be dropping the DB. :\.
- I manually fixed ~80 of these yesterday going back to the beginning of OUJS time. e.g. as early as 2013
- This message has been highly clipped for security reasons:
stderr:
2017-05-07 11:26:27.143 +00:00: MongoDB User save warning error
abego was NOT role elevated from User to Author with err of:
{
"code": 11000,
"index": 0,
"errmsg": "E11000 duplicate key error index: openuserjs.users.$_id_ dup key: { : ObjectId('*thisObjectIdHashClipped*') }",
"op": {
"__v": 0,
"name": "abego",
"role": 4,
"ghUsername": "*clipped*",
"_id": "*thisObjectIdHashClipped*",
"sessionIds": [],
"strategies": [
"*someAuthStrategy*"
],
"auths": [
"*clipped*"
]
}
}Current code point where this is generated when storing a script for the first time: .../blob/fac5ba5/controllers/scriptStorage.js#L1253-L1273
Refs:
- Typo fix #1106 (another correction to notification)
- Repair an
undefined#1105 (correction to notification) - Invert remote saves #1098 (added error trap notification)
User stat:
Stats
Member since
8h ago
Number of userscripts
1
Number of libraries
0
Total installs
0
Average installs
0
Average rating
0
Script stat:
Published: 6h ago
Version: 1.0
I will go ahead and elevate when these come through but this should be addressed so I don't have more work as Admin. (Manually elevated user abego)
Cc: @sizzlemctwizzle
Activity
Work-around to use a DB lookup to enable role elevation
Work-around to use a DB lookup to enable role elevation (#1108)
Martii commentedon May 8, 2017
Fully tested PR on dev by demoting myself to User then using GH import and does trigger this portion of the conditional... and elevates to Author. Pro keeps me at Admin level... which it should since that's outside the initial conditional... but triple checking to be secure.
sizzlemctwizzle commentedon May 9, 2017
My best guess is that instead of creating a new duplicate userDoc, retrieve the real one using find(), modify the role, save() it, and in the save callback, call the update method of libs/modifySessions.js to make sure the change is propagated in the session store.
sizzlemctwizzle commentedon May 9, 2017
Didn't notice this was already closed. Did your PR take into account saving the modified user doc doesn't propogate the change in role across active sessions?
Martii commentedon May 10, 2017
This is what the PR does... however...
This was never present before or after the PR. e.g. the
new User(userDoc)ended at that. See .../pull/1108/files#diff-b755ddbL1258See last response... e.g. never was there in the first place... understand the logic behind it though... just not sure where in the code to put the session change in. See prior emails about session managements.
Tiz okay... I follow everything. :) If there is a missing session propagation change a new issue would be preferable since it never existed.
Use static nums for role elevation check
Use static nums for role elevation check (#1137)