Can anyone please explain what Tokens, Users, Licenses means in Qlik Sense Desktop? In my QMC it says Unallocated 28% and 30 total token so what does this mean?
Agree with Carcigenicate. This question is more suitable for Qlik Community website where you can find this post/video
(QS Desktop don't have any users or licenses so i presume you are speaking for QS Server)
Basically you are buying tokens. Each token can be either User token or Session token
User token - personalized. 1 token = 1 user. The user have unlimited usage (no time limit). The user tokens are usually given to developers and heavy usage users
Session token - 1 token = 10 hours (per month) usage. Session token can be split across multiple users. Once the session token users consumed 10 hours of content the next token from the pool is allocated.
In your case you have 30 tokens in total. And some of them are allocated (being user or session tokens) and 28% have left un-allocated (8 tokens).
Related
I'm looking to secure my electron desktop app with user credentials (username + password), but I'm having a hard time finding the right technology to use. Requirements:
Number of activations can be determined (e.g. x copies of the app can be activated at any given time)
The user can deactivate/revoke access to all active instances remotely.
The activated copy will not need to be re-authenticated manually indefinitely if the user does not log out remotely.
For example, the user can authenticate themself, not use the desktop app for a long time then they aren't expected to log in again when they re-open it.
I am currently looking at JWT as it somewhat satisifes 2. However i've read that it's advised that the tokens not be saved in a database, so if I need to blacklist tokens, the blacklist would be a forever growing collection which is not ideal (unless you had a cronjob to remove expired tokens)
I'm not sure which solution would be ideal here that would meet the requirements.
Use JWT. Create two tokens: access token and refresh token. The access token will be short-lived (minutes), the refresh token will be long-lived (hours, days, weeks). Follow the best practice in token handling (Access token and Refresh token best practices ? How to implement Access & Refresh Tokens). Also comply with the OWASP ASVS V3 requirements regarding session handling
You actually do want the refresh token to expire. Else you would need to hold them in some blacklist forever. Forever is pretty long. Having to delete the expired logs from storage is a small price to pay for this level of flexibility you are willing to implement.
Make the refresh token hold two additional attributes:
Unique identifier
Human readable name
so the user knows which tokens he is invalidating. You would put into the blacklist the unique identifier and the expiration date.
You can identify how many copies of the application are being used based on the active access token count.
We are developing an integration with DocuSign. We use embedded signing and JWT authentication.
We received information from DocuSign Partner Solutions team that in JWT authentication, the expiration of the access token can be set by us to a long period of time.
based on that information, I designed the solution so we manually do the JWT authentication flow: get user consent, generate JWT, set expiration to one year and use it to obtain a long expiring access token.
now we went out of sandbox to production. We are testing the solution against a 30 days trail production account. We got user consent. I generate JWT and set expiration to various periods (one day, one month, one year) but I always get an access token that is good for one hour only.
PS, I went through the official documentation which states this about JWT exp property:
Defaults to one hour from the value of iat, and cannot be set to a greater value.
I wanted to know if anyone was able to generate long expiring access token out of JWT in DocuSign
The maximum grant time for access tokens received via the DocuSign OAuth JWT Grant flow is 1 hour.
The maximum grant time for access tokens received via the DocuSign OAuth Authorization Code Grant flow is 8 hours.
Good news for your application is that it is easy to obtain a new token via the JWT Grant flow: just re-run it within your app when the token that you have is about to expire or has expired.
No interaction with the user is needed since they have already provided consent (a one-time operation).
Note that the JWT Grant flow can fail, especially if the user has withdrawn their consent. Be sure to test this situation.
I'm sorry that you were given incorrect information.
I'm working on a digital board for meeting rooms. Every board, set outside the door of the meeting room, displays if it's occupied or not and the following meetings, according to it's calendar.
I followed this tutorial to create a JavaScript single-page app.
The problem is that after a while (less than 1 hour) I have to do the log-in again. I'm really struggling to find a solution to avoid it at all or reduce this frequency as much as possible.
Looking around it seems that working on the life of the Token is the answer. Refresh it or, even better, set it that never expires (until-revoked).
I've tried with PowerShell, following this guide but it doesn't work for the v2.0.
Azure AD does not support infinite lifetime Access Tokens. The hard limit for an Access Token lifetime is 1 hour.
However, Azure AD do support infinite chaining of the refresh token for new access tokens. When you modify the configurable token lifetime property and set it to until-revoked you are really doing this for the refresh token.
You must make sure you have proper logic in your code that tracks the expiration time of the access token, and requests for a new access token using the refresh token when the old token expires.
Can anyone say if following the instructions in the section entitled as per above in
https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension
allows long lived access tokens to be refreshed daily?
For the last two months, I've been generating a new long lived token each day, but today I got an expiration error message. I am definitely generating a new token each day, but does this token expire 60 days from its creation?
Many thanks
I found a way round this.
In response to your questions:
(a) I have a script that runs daily and that makes calls to the Facebook API. The reason why I want to create a new long lived token each day is because I do not want to keep track and see if I am near expiry
(b) It is possible to create a long lived token from a long lived token as per https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension#long-via-code under the section 'Generating Long-Lived User Tokens from Server-Side Long-Lived Tokens'
As far as I thought, Instagram does not invalidate access tokens based on their documents. But for a few users of the thousands using one of my applications built on their API, that does not seem to be the case.
I originally referred to the following SO question when initially building the application, and a few others - but I came to the conclusion (or so I thought) that Instagram does not invalidate tokens, which does not seem to be true: Instagram access token expire
Our application makes requests on behalf of a user at specific times of the day. It is an application that users may only need to ever log into once to utilize the service.
Here, for example is a user who signed up 4 days ago - his service was working great until this morning, when testing his access token we were receiving this response:
{"meta": {
"error_type": "OAuthAccessTokenException",
"code": 400,
"error_message": "The access_token provided is invalid."
}}
Why would this be happening on an access token that was valid 4 days ago? We asked the specific user this error is being returned for if he revoked access to our application or anything along those lines, and he did not.
I'm curious if perhaps he changed his IG password which invalidated his access tokens for applications (Although that doesn't seem likely as to what would cause this?)
Does anyone else have experience with Instagram applications randomly invalidating access tokens?
Also, note that 99% of users who have been using our application for a month or more have never had this issue. We've only encountered 3 to 5 other accounts this has happened with.
It's not really random. In fact an access token can be invalided in this 2 cases:
the user changed his password or where forced to do so (when IG thinks your account has been compromised).
they deleted the app the access token is linked to. (Or IG forces the app to be deleted if they suspect spam behavior)
But they do not expire from time.
From own experience the token can expire if:
the user removes the app
the Instagram account gets temporary locked which can happen if the Instagram user logs in from an unknown device/location (e.g. another country). The user is being asked to confirm identity by inserting an SMS code.
The second scenario is probably an Instagram bug. Why would the app token expire each time the account gets temporary locked? Would like to get an answer from Instagram as well.
NOTE: The token does not expire if user changes password.