Access user authorizationServer key from studio
-
we have talked about your case and we decided to include a way to get this token.
you will be able to access this using this code:
const jsreport = require('jsreport-proxy') const token = jsreport.authentication.getAuthorizationToken()this method will return the token associated with the studio SSO, and fallback to getting the value of
req.context.http.headers.authorizationwhen there was no studio session
-
working on the implementation revealed some issues, we are still evaluating this if it makes sense or not, it may take time.
for the mean time i think you are better checking the auth strategies you can handle against your app API
i mentioned that you can make your api return long lived tokens, or simple tokens that don't expire, this way you generate the token you need for all your app HTTP api access once and outside of jsreport, pass it as an env var at jsreport at startup and then just read the env var in your script, use this value when doing the HTTP request to your api. this flow is what you will normally when communicating with external services (because after all inside the studio your app HTTP API is an external source)
-
bjrmatos ADMINISTRATORS about 2 hours ago
we have talked about your case and we decided to include a way to get this token.Cool! Happy to hear that!
working on the implementation revealed some issues
Hope you will manage to overcome this :fingers_crossed:
pass it as an env var at jsreport at startup and then just read the env var in your script
We had such idea, but in this case all requests from studio will come from a single token and basically we will be forced to give this token superadmin privileges which is not ideal from security point (will not go over info sec department).
And after all, I guess, having different users in studio is one of the reasons for using authServer and not just sharing master password to all admins.
-
We had such idea, but in this case all requests from studio will come from a single token and basically we will be forced to give this token superadmin privileges which is not ideal from security point (will not go over info sec department).
And after all, I guess, having different users in studio is one of the reasons for using authServer and not just sharing master password to all admins.hmm you mentioned that the ones using studio are the admin users, the ones who can edit reports and create new ones, if they are going to do this, should not they already have all access to its tenant data when talking to your API? i mean if they are going to edit and create new reports, should not they already have access to all data available in its tenant space?
technically the token you will generate will only have superadmin privileges but for its tenant space, which they likely need to develop reports, is this not possible?
Hope you will manage to overcome this :fingers_crossed:
the issue we have is that we don't use the token returned by the auth server for any of our actions, it is not needed in our model. when getting a successful login in the studio we create our own session. since we don't need this token it is not stored, even if we store it, this token in the majority of cases needs revalidation (exchanging refresh tokens for new token) on expire, which is a procedure we don't execute in any part of the studio actions. we were planning to expose the token we get on studio login but the issue is going to be that after this token expire since there is no revalidation involved, what you are going to get is the expired token that was returned during the studio login, which likely your API auth will reject.
-
if they are going to do this, should not they already have all access to its tenant data when talking to your API
Role system is a bit more complicated, but it actually can be tolerated at the moment. Problem is the logging, since info sec requires all actions in system to be logged.
And in the case of a single token they all be logged under some technical account.
Maybe there is access to user data like email/name or something? Then probably with combination of a token, user data and studio server IP we can work something out.since we don't need this token it is not stored, even if we store it, this token in the majority of cases needs revalidation
I see... well I believe ouath2 allows non expiring access tokens with no refresh tokens.
And personally I am ok with this, but yeah, obviously it can be not optimal for other use cases.
-
Maybe there is access to user data like email/name or something? Then probably with combination of a token, user data and studio server IP we can work something out
do you mean if we can let you access in script the user email or name associated with the token?
I see... well I believe ouath2 allows non expiring access tokens with no refresh tokens.
And personally I am ok with this, but yeah, obviously it can be not optimal for other use cases.since the studio login is based on OpenId connect SSO, i don't believe the standard allows retrieving non expiring tokens, but even if allow it, the solution of just letting you access the token received at login and without any revalidation does not look good, the majority of cases are going to be with token with expirations
-
do you mean if we can let you access in script the user email or name associated with the token?
Yes, current studio user's email
since the studio login is based on OpenId connect SSO, i don't believe the standard allows retrieving non expiring tokens, but even if allow it, the solution of just letting you access the token received at login and without any revalidation does not look good, the majority of cases are going to be with token with expirations
Yeah, looks like a bigger deal
-
Yes, current studio user's email
i think we can do this, we will discuss this internally, likely you will be able to access it with
req.context.user.name, if the name of your user is your email then this is going to work for your. we will check.
-
Hi!
Have you had a chance to discuss it?
-
we are adding it, it is going to be part of next release which we are currently working as i write this
