I have a Mule application which uses the Salesforce connector.
When I started developing this application, I first used oAuth to connect to Salesforce, but it kept giving me the following error: Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session key: <key>, so I switched to basic authentication for Salesforce.
This has worked great, but now, after some time, the application still throws the Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session key: <key> error.
This is unexpected behaviour, since each request contains the username, password and secret token.
It looks to me like some old version is in the Mule cache or something, which makes it want to use the oAuth method again. Is this a possibility?
Any ideas on how to fix this?
#Sytze You need to check the flag in the Salesforce connector for all applications sharing the same user credentials to Disable session invalidation (disableSessionInvalidation="true"). What is likely happening is one of your other applications is invalidating the session while your current app still believes its active.
In the connector configuration , check for the correct Token code ( generated via sfdc ) .
Update the latest code and try again
Your security token that you add with your password while calling it would have expired. Create a new token for you account/email-id in salesforce and use that and it should work
Best would be to use the oAuth to call salesforce.
Related
In my jmeter web recording, I have an api/authenticate part which generates the token which has to be used
in subsequent requests. I did the part of correlation too. But the problem I face now is, the api/authenticate throws a session still persists error after sometime. In my script I have log out option too. In api/authenticate I am providing username and password in the headers. Since the session exists error is there, I can't get the token in the response body. Is it something that developers can fix for us? can you please help me with this? Or is there any request which is missing above this authentication part which jmeter didn't capture? I have authentication header manager added to my test plan to clear
authorization every iteration. Also cookie manager and cache manager. Nothing clears the session.
For well-behaved application "log out" request should clean the session, if it doesn't - you need to report it to your application developers.
Also check the token response, it might be the case it has some time to live and if this is the case the token persistence could be a part of your application functionality so if there is a username/password combination associated with the token you should be using it until it expires before getting the new one. So you can write the token and its expiration date into a CSV file using Flexible File Writer and use If Controller to check whether the token is still active or not
I started working with adding migration from OAuth1a to OAuth2 inside my application and i face some problems.
This is what I've done :
I updated my partner app just like it is described here https://developer.xero.com/documentation/oauth2/migrate (added Auth2.0 redirect , got client id and secret etc ...)
I implemented token migration exactly as it is done here https://github.com/XeroAPI/xero-net-oauth2-sampletokenmigration and it works fine when OAuth1 token is valid :)
But when it is invalid and I'm doing refresh (using app updated in step 1) and call ~/oauth/migrate endpoint (using access token that i just recived after refresh step) to get OAuth2 token. I'm reciving this error "You can only migrate an OAuth1.0a connection to an OAuth2.0 connection for the currently authorised app". Also same thing happen when i create new connection (using partner applications created in in step 1) and than try to migrate this access token to Auth2.0.
Can anybody point me what I'm doing wrong ?
That is the error returned when you try to migrate to a newly created app. Are you sure you are using the tokens from the same Partner app tile in your /myapps dashboard.
It should look something like this, once you've added the correct OAuth2 redirect uri and generated your secret.
I'm trying to acquire a 2 legged oauth2 access token for google's storage api through a service account.
The relevant documentation is contained here:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount
I first tried attempted to acquire the token through their HTTP/REST api. I eventually gave up being unable to get past a 400 response with the following details:
{ "error" : "invalid_grant" }
I then turned to the recommended method: using the java Google api client library (I'm using scala).
val credentialBuilder = new GoogleCredential.Builder()
.setTransport(GoogleNetHttpTransport.newTrustedTransport())
.setJsonFactory(JacksonFactory.getDefaultInstance())
.setServiceAccountId(Configuration.GoogleAPI.ServiceAccount.email)
.setServiceAccountPrivateKeyFromP12File(new File(Configuration.GoogleAPI.ServiceAccount.pkcs12))
.setServiceAccountScopes(Collections.singleton(StorageScopes.DEVSTORAGE_FULL_CONTROL))
def updateToken = {
val credential = credentialBuilder.build()
credential.refreshToken()
// ... do stuff here with token
}
Running the above, I get a TokenResponseException, with a payload identical to the error I was getting directly accessing the REST api. 400 Bad Request, invalid_grant error.
Doing some research (on both stackoverflow and elsewhere), I find that the most common reasons for this error message are:
1) The local clock is not synced with Google's servers. I suspected this even back when I was using the REST api because I've encountered this issue for other services before. I'm fairly sure its not a clock issue however, because I have repeatedly synced my clocks with an external ntp server:
sudo ntpdate -s ntp.ubuntu.com
2) The other common cause for this error is setting the service account client ID incorrectly. Most people set it to their service account client id (ending with "apps.googleusercontent.com") instead of their service account client email. Its pretty clear that this isn't the problem, since I'm correctly pointing to the email (the docs instructed this, so I followed the directions), ending with "#developer.gserviceaccount.com".
I'm stuck. I've checked the user documentation, the javadocs, various forums. The error message isn't very helpful (probably designed that way, since it's a security endpoint).
What other possible causes for this error exist? What can I do to get my service account access token?
If you are using OAuth2.0 to access a google analytics account then there could be one more reason of getting invalid_grant. As per developer docs:
If the application attempts to use an invalidated refresh token, an
invalid_grant error response is returned. The limit for each unique
pair of OAuth 2.0 client and Google Analytics account is 25 refresh
tokens (note that this limit is subject to change). If the application
continues to request refresh tokens for the same Client/Account pair,
once the 26th token is issued, the 1st refresh token that was
previously issued will become invalid. The 27th requested refresh
token would invalidate the 2nd previously issued token and so on.
My problem is as follows :
I have an application protected by a mobile security test involving a LDAP server. The corresponding realm is called LDAPrealm. I use the form-based authenticator + custom LDAP login module.
When the connection to the worklight server is lost and then re-established, I see that the current user is not authenticated in the LDAP realm anymore.
What I want is be able to re authenticate the user without having him enter credentials again.
However, since the user is still authenticated for other realms included by default in the mobile security test, the worklight server does not challenge the client again for credentials, which is causing j_security_check error when trying to submit credentials.
As a side note those credentials are stored in the encrypted json store for offline authentication and use of the app.
So my question is :
Is it possible to force the server to challenge the client again for this LDAPrealm and use submitLoginForm to re-log in?
More generally, is there a way to clear a user+device from all realms before trying to log in again?
Edit reasons : previous error was caused by a typo
In the case where the user first logs in online then loses connection then get connection again, calling
WL.Client.logout("LDAPRealm",{onSuccess:stealthed_relog});
and calling WL.Client.connect() later in stealthed_relog before sending credentials seems to wield the desired behaviour.
However, when the user logs in offline and then gets connection, when I try to use WL.Client.connect(), it says another instance of WL.Client.connect has already been called.
edit : for the log offline case, the application get challenged automatically shortly after that the connected event fires (cause of heartbeat? I do not really know), so you just have to use
login_clientside.submitLoginForm();
to successfully log in again.
If someone has a better way to implement auto-reconnecting in worklight with ldap server, feel free to post it and I'll unaccept my answer.
I'm using openDJ LDAP server for authentication process of a Java based project using JNDI.
Most of the other things like password expired, invalid credentials can be handled using exceptions. (using the understandable message in exception, or using the error codes in some occasions)
ds-cfg-force-change-on-add and ds-cfg-force-change-on-reset attributes are set to true in the password policy.
But when a newly created user logs in or, when a user logs in after a password reset by admin no exceptions occur.
Can somebody tell me how to handle this.
One alternative in this case is the password policy request and response controls (example) defined in draft-behera-ldap-password-policy, supported by OpenDJ LDAP SDK and other SDKs. You pass the request control to the directory server, and you get back a response control.
The response control indicates whether the password needs to be changed, why a requested password modification could not complete, how much time remains before expiration, etc.