qcaas-nhs-sjt
commented
7 months ago Forgot to mention am using Entra ID via OpenID Connect
@chrisknoll don't suppose you're able to push me in the right direction for this?
Open qcaas-nhs-sjt opened 7 months ago
qcaas-nhs-sjt
commented
7 months ago Forgot to mention am using Entra ID via OpenID Connect
@chrisknoll don't suppose you're able to push me in the right direction for this?
qcaas-nhs-sjt
commented
7 months ago I've investigated this issue and it appears that it is looking for a property that is not present in the output from the WebAPI called permissionIdx
const loadUserInfo = function() {
return new Promise((resolve, reject) => $.ajax({
url: config.api.url + 'user/me',
method: 'GET',
success: function (info, textStatus, jqXHR) {
permissions(info.permissionIdx); // read from permission index of User info
subject(info.login);
authProvider(jqXHR.getResponseHeader('x-auth-provider'));
fullName(info.name ? info.name : info.login);
resolve();
},
error: function (err) {
if (err.status === 401) {
console.log('User is not authed');
subject(null);
if (config.enableSkipLogin) {
signInOpened(true);
}
resolve();
} else {
reject('Cannot retrieve user info');
}
}
}));
};I've therefore in our fork created a fix for this which takes the required data from the permissions field instead:
const loadUserInfo = function() {
return new Promise((resolve, reject) => $.ajax({
url: config.api.url + 'user/me',
method: 'GET',
success: function (info, textStatus, jqXHR) {
const permissionIdx = info.permissions.reduce(function(rv, x) {
key = x.permission.split(":")[0];
(rv[key] = rv[key] || []).push(x.permission);
return rv;
}, {});
permissions(permissionIdx); // read from permission index of User info
subject(info.login);
authProvider(jqXHR.getResponseHeader('x-auth-provider'));
fullName(info.name ? info.name : info.login);
resolve();
},
error: function (err) {
if (err.status === 401) {
console.log('User is not authed');
subject(null);
if (config.enableSkipLogin) {
signInOpened(true);
}
resolve();
} else {
reject('Cannot retrieve user info');
}
}
}));
};With this done I am able to access what I need:
I'm not sure whether I'm doing something wrong with our versioning or something, hence I've not raised a PR for this yet, I'd like someone more familiar with the codebase to look at this. Though you can see the change here:
https://github.com/lsc-sde/fork-ohdsi-atlas/commit/a10f9dad3ea2c8e91850e2b1292352b98d451ea5
We are using a docker image built from master branch of the Atlas repository, our webapi is currently using docker image:
ohdsi/webapi:2.14.0
chrisknoll
commented
7 months ago That's the problem, there's an update in Atlas Master that depends on master webAPI. So either grab the atlas UI tagged to v2.14.0 or rebuild your WebAPI with master branch.
qcaas-nhs-sjt
commented
7 months ago That's the problem, there's an update in Atlas Master that depends on master webAPI. So either grab the atlas UI tagged to v2.14.0 or rebuild your WebAPI with master branch.
Yeah thanks I literally just figured that out, had tried reverting back to 2.14.0 on both repositories previously but I guess the change didn't take for whatever reason which led me down the rabbit hole. I'll try reverting again and hopefully that will solve the problem. Thanks for your assistance, it is greatly appreciated
We are currently using Atlas 2.14.0 and WebAPI 2.14.0 via docker container images, the authentication seems to be working properly, I can login to the site and I can see that I'm logged in:
I'm setup in the database with the same rights as the default admin user.
and I can see that I am getting a response from: /WebAPI/user/me
Yet I get told that I do not have any access on every screen:
There is nothing in the web api logs that I can see which help and nothing in the console logs.
Any thoughts on what this issue might be would be appreciated