Access user authorizationServer key from studio

[CrazyClicker]

Hello everyone!

Currently I'm trying to setup communication between my own app and jsreport.
I was able to authenticate my users in jsreport through authorizationServer and now have sql table with their oauth keys.

What I need to do now it is to use my app's API from jsreport studio scripts. I need this calls to be made from current user using studio. Can I somehow access his auth key?

[bjrmatos]

hi!

What I need to do now it is to use my app's API from jsreport studio scripts. I need this calls to be made from current user using studio. Can I somehow access his auth key?

this depends on how your app's API authenticates the call, what does it expect? is it a token in the Authorization header? i am not clear what specific value from authorizationServer you want to reuse

[CrazyClicker]

Hey! Thanks for reply!

Since I have full control of my app I am flexible on that part. Since we use extensions authentication authorizationServer and already generate and return access_token to jsreport I thought that maybe it can be used for reverse authentication for API calls from studio.
But once again, I can adapt to other strategy if there is one. The main goal is to authenticate user specific API calls from studio to my app without master login/password for all requests.

[bjrmatos]

Since we use extensions authentication authorizationServer and already generate and return access_token to jsreport I thought that maybe it can be used for reverse authentication for API calls from studio.

so, do you want to reuse such access token and use it for api calls from scripts?

if you enable the extensions.express.exposeHttpHeaders to true then you can get the headers that contains the token from script.

in the script you can do this, can work with the header to extract the token from there

async function beforeRender (req, res) {
    // you can also log all the headers so you better understand what it is in there
    console.log(JSON.stringify(req.context.http.headers, null, 2 ))
    const authorizationHeader = req.context.http.headers.authorization
    console.log(authorizationHeader) // should log "Bearer xxxxxx"
}

[CrazyClicker]

Hi! Sorry for long delayed answer, focus shifted a bit.
We are now back to this task. I've added exposeHttpHeaders flag and can see contents of https.headers object but there is no authorization property or anything similar.

[bjrmatos]

i did a quick test using the same script as you provided and i can see the authorization header getting logged as expected

i have triggered the request from RapidAPI (macOS HTTP client).

how are you executing the request?

[CrazyClicker]

I probably described my scenario poorly.

1. I login in jsreport studio with "Login with authserver".
2. My app authorizes user and issues token
3. In Jsreport studio I ran report by simply clicking "Run" button
4. Report executes script.... and what I need to do is to request my app for data and I need to authenticate with my app somehow, so I thought that it is possible to use token from step 2

[bjrmatos]

ahh ok, this is different execution flow. yes, when the render comes from studio there is no way right now to reuse the token.

i think you will need to manually pass it to your script for your testing

not sure how common this case is but exposing the token to the render sounds dangerous, of course it is fine if you just do it for testing and preview, but for the rest of cases it looks a bit wrong, maybe the solution is that you configure your auth server for these dev scenarios to always returns the same token and that it has no expiration (or just a really long one), this way after you are done creating and testing templates in studio you just disable this long lived token.

[CrazyClicker]

Sorry, I probably don't get some right way to do it. But what are even other ways to authenticate js report studio user with app, I mean not for testing, but for production?

I have an App and I want to add report generating functionalities with JS Report and JS Report studio.

I can login users to JS Report studio with external authserver (my app essentially) but what can I do next?
I need users to be able to execute reports that retrieve data from the app. To retrieve data from the app I need to authenticate in the app. What are my options?

[bjrmatos]

I have an App and I want to add report generating functionalities with JS Report and JS Report studio.

curious to know, in this case why you need your users to authenticate in jsreport? is it not enough that report generation is an under-the-hood feature in your app powered by jsreport? that internally by some UI in your app you let them generate the report they want, but internally you call jsreport HTTP API and deal with the authentication to get the report? i guess this depends on the type of users you have, if your users are people who understand html then it makes sense to expose the templates directly in jsreport studio, however if you just want users to get a list of templates and want they get report output by clicking some button, then it looks better that you integrate your app with jsreport via HTTP API and expose this feature via custom UI

[bjrmatos]

hen it looks better that you integrate your app with jsreport via HTTP API and expose this feature via custom UI

with this method you can just re-use the token you send in HTTP API with the expose headers feature in your scripts

[CrazyClicker]

Hi!

Overall case is that we install our app on premise and our client have two group of users: admins and, well, users.
We install app with preconfigured set of reports.
And the goal is to let admins (who have basic html/js knowledge) edit reports and create new ones.

Problem with HTTP API approach is that we don't know beforehand what data they need. We provide our own API and want user to query it from his report to retrieve data.

I'll make an example:

1. We shipped "Blog post by week days" report with our app
2. Admin wants to add info about comments count to report, but data set lacks comments info
3. ? If he can get authorization in our app's API from jsreport studio he can get this data.

[bjrmatos]

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.authorization when there was no studio session

[bjrmatos]

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)

[CrazyClicker]

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.

[bjrmatos]

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.

[CrazyClicker]

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.

[bjrmatos]

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

[CrazyClicker]

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

[bjrmatos]

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.