function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
pidruspidrus 

Getting "Invalid username or password or locked out" when connecting to sandbox

Hi!

 

I have a Java application that logd in fine to the production account, but I'd like to have it connect to the sandbox account for testing purposes.

 

I have:

 

1. changed the username by appending the sandbox name at the end

2. made sure the password is correct

3. re-generated the security token and appended it at the end of the password

4. re-generated the WSDL file and replaced the production WSDL with the sandbox one

 

However, I'm still getting this error.

 

Searching this forum, I found:

 

http://community.salesforce.com/sforce/board/message?board.id=JAVA_development&message.id=4885&query.id=64302#M4885

 

But that didn't help either.

 

My gut feeling tells me the production WSDL was somehow cached.

 

So:

 

1. Does anyone know how to force re-cache or alternatively disable caching all together? (I found some PHP code for that but not for Java)?

 

2. Does anyone have another idea on how to approach this problem.

 

I'm a senior developer but a newbie to both Java and SalesForce, so please explain slowly using simple words... :)

 

Thank!

 

Ilan.

rfisher000rfisher000

Are you using the correct endpoint for the sandbox?

 

I beleive I have "test" swapped out with "www" in the URL.

pidruspidrus

Yes as far as I can tell.

 

The only place I saw the URL is in the WSDL file.

 

The production file points to: 

 

 

<soap:address location="https://www.salesforce.com/services/Soap/c/8.0"/>

 

 and the sandbox one points to:

 

 

<soap:address location="https://test.salesforce.com/services/Soap/c/16.0/0DFR00000008Rm3"/>

 

 That's why I have a feeling the production WSDL is being cached, so that when I'm using the sandbox credentials it still goes to the production URL and login fails...

 

 

rfisher000rfisher000

Here is a code snipet if it helps.

sforce_port.setEndpoint(sf_url); LoginResult lr = sforce_port.login(login_id, password, lsh); sforce_port.setEndpoint(lr.getServerUrl());

 

 

I believe I am overiding whatever the WSDL points with that first call to setEndpoint().

I have a properties file that controls pointing to production or the sandbox.

I also beleive the second setEnpoint is important incase SF tells me to use a different server (load balancing on there end).

pidruspidrus

Thanks for the idea, I think this is the right direction.

 

Not sure why there is a difference, but my code looks like this:

 

 

binding._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, SFDC_LOGIN_URL); lr = binding.login(userName, pwd); // Reset the SOAP endpoint to the returned server URL binding._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, lr.getServerUrl());

 

The problem is that I get the following exeption from the login call:

 

nested exception is: java.lang.IllegalArgumentException

 

I'm looking into that now...

 

 

Message Edited by pidrus on 06-29-2009 11:18 AM
rfisher000rfisher000

This is where it gets complicated.  I'm enough of java newbie that I'm really not sure why I have this setup they way it is, or if there is a better way.

 

In the process of importing the Enterprise WSDL a SoapClient is created.  This client has all the SF native methods (insert, update, upsert, etc.) and it also includes a few JAX-RPC methods including getEndpoint and setEndpoint.

 

So sforce_port is the instantiation (I think that's the correct Java word) of that class in my code.

 

Hope that helps, maybe someone more knowledgeable can take over.

SuperfellSuperfell
What's the value of the sf_url variable ?
rfisher000rfisher000

Depending on whether I am in test or production:

PROD_URL=https://www.salesforce.com/services/Soap/c/14.0
TEST_URL=https://test.salesforce.com/services/Soap/c/14.0

mpiercempierce
Can you provide the full stack trace on that exception?
pidruspidrus
It turns out you need to generate a separate security token for the sandbox... duh :)