The key value expired during drm development, so I called back using SbDrmSessionUpdateRequestFunc,
'LOG (ERROR) << "Unknown session update request ticket:" << ticket << "." A log will appear.
Why is this log coming out?
Is the session_id value the same until the video starts and ends?
ticket should be kSbDrmTicketInvalid if the update request was generated by the DRM system.
Related
I am getting the following response when calling the /accounts/balances/get endpoint in the development environment. After getting this, I'll use update mode to get a new access_token. Once I swap in the new token, everything works fine for about an hour and then this error will occur again. I am 100% not making any updates on the bank side.
{ display_message: null,
error_code: 'ITEM_LOGIN_REQUIRED',
error_message: 'the login details of this item have changed (credentials, MFA, or required user action) and a user login is required to update this information. use Link's update mode to restore the item to a good state',
error_type: 'ITEM_ERROR',
request_id: 'redacted',
suggested_action: null }
Does the login associated with the Item have "perpetual OTP" enabled -- i.e., is it configured so that you need to enter a 2-factor authentication token every time you log in to your bank, even on a trusted device?
If so, this is expected behavior -- once your original session expires, Plaid requires a user to be present to provide a new token and create a new session to get fresh data.
If not, there may be an issue with the integration between Plaid and the specific financial institution. If that's the situation, you should file a support ticket with Plaid so we can investigate further.
I'm sending my push notifications with an APNs Auth Key ("never expires") which worked well until suddenly I get
403 Forbidden: {"reason":"InvalidProviderToken"}
as a response when sending push notifications. What could be the reason for this when it worked once and suddenly it doesn't without having an expiration date? In the meantime it worked again for some pushes, but now I get the error again... Did anyone else experience this?
EDIT
Not sure but it seems as if this only happens on the Ubuntu server, not on my local (OS X) machine...
we have exactly the same problem when sending pushes to different team ids using the same connection. The steps to reproduce are:
Open a connection to APNS and use the same connection to:
Send a token based push to topic com.companyA.xxx of team id 1234: APNS accepts and delivers the push successfully.
Send a token based push to topic io.companyB.xxx of team id 5678: APNS responds HTTP 400 BadRequest The device token does not match the specified topic
Send again a token based push to topic io.companyB.xxx of team id 5678: APNS responds HTTP 403 Forbidden: the provider token is not valid or the token signature could not be verified.
After this it becomes impossible to send any push and the connection has to be closed and reopened.
The workaround we ended up doing is to open one connection per team id. The APNS documentation does not mention anything like that so I do consider this as a bug and I opened a bug report.
I've seen this in a couple of circumstances:
Resubmitting expired provider tokens seems to get the token blacklisted and results in subsequent InvalidProviderToken rejections rather than ExpiredProviderToken rejections. Check you logs for token expiry messages. Check your system clock to make sure that you're not generating tokens with skewed timestamps.
Submitting to invalid topics will invalidate all provider tokens on the connection (even previously valid ones). Only submit to topics that the key is bound to and only use one key per connection.
For me, there was an issue with bad configuration. I was using the wrong Team ID. Please make sure that all configuration is correct before you look into any other solutions.
The server does respond with an InvalidToken and/or an ExpiredToken error. Your authentication token shouldn't contain any '=', '+', '-', Double check if your token hasn't this any of those. Also the signature (3rd part of the token, should be Base64URL encoded, so without the previous mentioned characters).
for me the server time was invalid, fixing the server time solved the issue
I asked Apple to change my account from a personal account, to a business account. My push notification certificate still said everything was fine, but the notifications weren't working, and I was getting the response Invalid Token. Once I revoked the certificate and issued a new one (in apple connect), everything worked fine.
I wasted so much time trying to figure out why the push notifications weren't working. Hopefully this will save someone else some time!
I had been using the Name of the key instead of the Key ID. Verifying on https://developer.apple.com/account/resources/authkeys/review/ showed the correct value.
My case is with the json pretty print format. Unlike musickit which can accept jwt pretty print format, the APNs only accept the raw format.
In details:
My message was:
{
"alg": "ES256",
"kid": "SOMEKEYID"
}
{
"iss": "SOMETEAM",
"iat": 1581110460
}
I verified the result jwt via jwt.io, however the APNs keeps telling me InvalidProviderToken. I have tried everything above. No use.
Finally I changed the message to:
{"alg":"ES256","kid":"SOMEKEYID"}
{"iss":"SOMETEAM","iat":1581128155}
then it pass with no error.
Turns out APNs do not accept json pretty format!
Apple's APN documentation says:
APNs supports only provider authentication tokens that are signed with
the ES256 algorithm. Unsecured JWTs [JSON Web Tokens], or JWTs signed
with other algorithms, are rejected, and your provider server receives
the InvalidProviderToken (403) response.
So, it appears that the problem is not with your auth kiey; it's actually an issue with the web token that was generated from your key.
I have an application in rails which is heavily based on facebook oauth2. At a glance - user signs in with FB connect and can list it's pages (and do some stuff with that data but that's not important right now. Let's just focus on signing-in and getting pages list).
After a sign-in, i'm saving user access_token and expires_at in the db. Then, each time i need to make a request to facebook api as a user (to obtain his pages list), i'm checking if expires_at is not past and if it is, i'm renewing user token using a following snippet:
def refresh_facebook_token
# Checks the saved expiry time against the current time
return unless facebook_token_expired?
# Get the new token
new_token = facebook_oauth.exchange_access_token_info(
old_access_token)
# Save the new token and its expiry over the old one
self.facebook_auth = {
uid: uid,
access_token: new_token['access_token'],
expires_at: Time.now + new_token['expires'].to_i
}
save
end
This works most of the times but, from time to time, my code throws:
type: OAuthException, code: 190, error_subcode: 460, message: Error validating access token: Session does not match current stored session. This may be because the user changed the password since the time the session was created or Facebook has changed the session for security reasons. [HTTP 400]
in line with exchange_access_token_info.
That error is thrown fo my own user and i can say that i didn't changed the password so i'm not sure what's that caused by nor how can i deal with refreshing the tokens by backend in a bullet-proof way.
Any help much appreciated!
First of all, I would recommend you go through this link and decide which configuration makes sense for your application - using short-lived or long-lived or what.
Now, am not too sure but I think that you are considering the method exchange_access_token_info as the token refresher. If so, this is NOT the case! Once a token is expired, it's useless.
exchange_access_token_info method simply takes the short-lived token (which is currently active) and convert it into the long-lived token using app id and secret.
Just understand that-
The user access token cannot be extended infinitely again and again without any user's interaction with your app for 60 days.
So the flow is very simple-
you get the short-lived token when user authenticates your app (user engagement on front-end)
on server-side you extend the token's validity to 60 days.
want to extend the token validity again? - repeat the steps.
Hope that helps!
Does anyone know how long would it take for the token to expire? There no option now to set the token validity on the console.
Since May 2016 Firebase Authentication login sessions don't expire anymore. Instead they use a combination of long-lived account tokens and short-lived, auto-refreshed access/ID tokens to get the best of both worlds.
If you want to end a user's session, you can call signOut().
Its does expire. After one hour logged in the token id expire. If you try to verify sdk returns a error "Error: Firebase ID token has expired. Get a fresh token from your client app and try again. See https://firebase.google.com/docs/auth/server/verify-id-tokens for details on how to retrieve an ID token."
Is There such a way to change expiration time to Firebase token, not custom token.
Anybody that know how this really works.
For anyone that is still confused, it is all explained in great detail here
If your app includes a custom backend server, ID tokens can and should
be used to communicate securely with it. Instead of sending requests
with a user’s raw uid which can be easily spoofed by a malicious
client, send the user's ID token which can be verified via a Firebase
Admin SDK (or even a third-party JWT library if Firebase does not have
an Admin SDK in your language of choice). To facilitate this, the
modern client SDKs provide convenient methods for retrieving ID tokens
for the currently logged-in user. The Admin SDK ensures the ID token
is valid and returns the decoded token, which includes the uid of the
user it belongs to as well as any custom claims added to it.
If the above answer is still confusing to you,
This is what i did:
firebase.auth().onAuthStateChanged(async user => {
if (user) {
const lastSignInTime = new Date(user.metadata.lastSignInTime);
const lastSignInTimeTimeStamp = Math.round(lastSignInTime.getTime() / 1000);
const yesterdayTimeStamp = Math.round(new Date().getTime() / 1000) - (24 * 3600);
if(lastSignInTimeTimeStamp < yesterdayTimeStamp){
await firebase.auth().signOut()
this.setState({
loggedIn: false
});
return false;
}
this.setState({
loggedIn: true,
user
});
}
})
In my application I use web services to get required information. To actually use this services you have to login first, you get your token - encrypted password, afterwards this token is attached to SOAP requests to identify current user. The thing is, when you do not use service for 15 minutes, your token changes and when you are trying to obtain another bunch of information from the server it denies old token. As a result app do not get required information and throws a heap of errors.
How to send user (load Login.axm) to Login page when token has been changed?
Thank you, Shay Shmeltzer for your answer.
How I solved this problem:
1) First I read how does sessions work in my particular case. I used stateless session which means -
A new session is opened for an initial request and the session remains
open for subsequent requests. Relogin occurs automatically
(transparent to the user) if the session is closed. UsernameToken and
PasswordText must be included as SOAP headers in the initial request
to open a stateless session.
Stateless session management is the best method to use for high-load
Web service applications. Using Stateless mode, the application
provides the username and password only once, that is for the initial
request. A session is opened on the server and is dedicated for this
user.
In the response Siebel Business Applications return the SessionToken,
which is an encrypted string containing the information about
username, password, and timestamp. For subsequent requests the
application must use the SessionToken to reuse the session.
For security reasons SessionTokens are regenerated for each response.
The application must provide the last received SessionToken for the
next request.
The SessionToken-Siebel session map is maintained in the Siebel Web
Server Extension (SWSE); based on the SessionToken value SWSE sends
the request to the correct Siebel session (task).
Although the session is persistent, authentication happens for each
request (SWSE decrypts the UserName and Password from the
SessionToken).
the main problem was :
NOTE: Reconnecting or automatic logging in again will only happen if
the token has not timed out. If it times out, then the user must
manually log in again. Token timeout must be greater than or equal to
session timeout. For more information on session token timeout, see
Session and Session Token Timeout-Related Parameters.
in my case standard session token live time was 15 minutes.
That is why I included counter in my code and checked it before each request. If counter time > 15 minutes, I sent log in request to the server to get new session token. The reason, I did not change current page to log in page straight away after the counter exceeds 15 minutes is: place in code, where I check counter is already initiated by the bindings to get required value to render it, so if your token has expired you will get a heap of errors. That is why firstly I renew the session sending log in request, get active session token and put it into the last request which is requested by binding. After app renders page without any errors, it shows pop up message "Session has expired" and goes to log in page.
You can programmatically set the soap header being sent to your SOAP service from ADF Mobile - http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/amxwebservices.htm#CHDIBIIE