We’re at a loss for what to consider with this issue. The server logs don’t reflect a problem–it is only visible in the browser console. Does anyone have suggestions for where to look to resolve?
Unfortunately this is still unresolved, as no one can view their results. A 403 suggests an authorization issue, but I can’t see a problem in the Postgres DB, and can’t associate any changes to this problem, as there haven’t been any application updates in over a year. Users can create them but not view. What else could we check, as the permissions look correct?
Which version of Atlas are you using?
There was a bug where a general permission to view results was deleted whenever a specific characterization was deleted, and the painful part about this is that you’ll have to restore the permission manually in the permission table, but I can give you specific instructions on that.
Here’s some debugging SQL i use to find out if a user has the permission:
select * from webapi.sec_permission
where value like 'cohort-characterization:generation:*%';
select * from webapi.sec_user where login = 'someUser';
select distinct p.id, p.value
from webapi.sec_user_role ur
join webapi.sec_role_permission rp on ur.role_id = rp.role_id
join webapi.sec_permission p on p.id = rp.permission_id
where p.value like 'cohort-characterization:generation:*%'
and ur.user_id = 1029;
First query just checks if the perm exists, it does for you it appears.
Next query willf ind the user ID based on my login, I’ll need that user_id to locate my permissions.
Last query joins to find a user’s roles, to locate the assigned permissions for the given user, and then filter to those limited to the permission we are looking for.
So, it’s possible that maybe a role was removed from a user or a permission from a role and this person doesn’t have the permission assigned to them.
Chris,
Running your queries made it obvious there was one GET permission missing from the Atlas users role (the last one in the screenshot). So I added it manually to the role_permission table and it finally works.
Given this permission has such a high number, and hence very recent, it appears to have been dynamically generated and I noticed that only two users have this permission attached to their named user role, which implies other users would not be able to access it without the admin step of explicitly adding it to the broader Atlas user role. Perhaps there is something amiss with our configuration that would cause this, or is it a bug, or it is by design?
For the record:
INSERT INTO ohdsi.sec_role_permission(
id, role_id, permission_id, status)
VALUES (6737, 10, 5648, NULL);
Thanks so much for the assistance!
Hi @Dillo , glad you got it working. Let me explain root of the bug (which is fixed in 2.15 which will be released shortly). You can get the details from the above
When creating a characterization, a new permission is created for it based on the ‘permission template’ that is described in the above issue. This new permission is granted to the user. The bug was one of the permissions was not id-specific, but instead was a general (known as ‘wildcard’) permission. his means that when someone deletes a characterization, it removes all the id-specific permissions (which is correct) but additionally deletes this wildcard permission. That’s why you saw some permissions granted to specific users (because it was greanted via the creation) but others couldn’t see results because the general user permission was deleted.
The fix is to crate the permission, and then you should add it to the Atlas user role. Which you did, so kudos to you.
However, if anyone deletes a characterization (due to the existing bug in versions up to 2.14), you’ll have the same problem again: the permission will be deleted, and you’ll have to re-create it and assign to Atlas user again.
The current permission structure has some flaws, and we’ll be re-vampign it in the 3.x release of Atlas/WebAPI. Once 2.15 is released, hopefully you can upgrade to that and that will address this ‘vanishing permission’ problem.
Ok, thanks for explaining. Any rough estimated timeline on 2.15?
One more thing. Inserting to the highest number as shown above later resulted in a primary key violation due to the auto-incrementing to the same id number, so I had to delete that insert and found a gap in the table with no key.
If you have your postgres browser, you’ll see that there are sequences created that are used to generate primary keys.
Int his case, you want the sec_permission_id_seq and the way you would use it is:
INSERT INTO ${ohdsiSchema}.sec_permission (id, value)
VALUES(nextval('${ohdsiSchema}.sec_permission_id_seq.'),
'characterization:etc:etc');
But it’s fine to find a gap, since it was a permission that shouldnt’ have been deleted, it’s possible to have found the origional ID, but I wouldn’t worry about it, but you definitely want to use the sequence or find a gap to fix it.
2.15 should be out mid July.
1 Like