3. Access user authorizationServer key from studio

Access user authorizationServer key from studio

  • administrators

    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

    0
  • C

    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.
    0
  • administrators

    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

    0
  • administrators

    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)

    0
  • C

    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.

    0
  • administrators

    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.

    0
  • C

    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.

    0
  • administrators

    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

    0
  • C

    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

    0
  • administrators

    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.

    0
  • C

    Hi!

    Have you had a chance to discuss it?

    0
  • administrators

    we are adding it, it is going to be part of next release which we are currently working as i write this

    0
Log in to reply
 

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.