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
PrafPraf 

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session

Hi,

 

We have a custom integration that was built using version 10 of the API and it works fine. I am testing out adding some new functionality to the application which will retrieve some data for me and keep getting the error message

 

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session

 

The application uses a partner WSDL, lets call this code A. There is a button on our SFDC org that launches another application, code B, which recieves certain params when invoked like server url, session id, username etc etc. Code B passes these params to code A who then tries to login to SFDC org to validate the session id and user settings etc.

The above works on one of our dev and prod instances but returns an error on our sandboxes.

 

Below is the session header that code A uses to make an API call to SFDC, could someone look it over and let me know if I am missing something here, maybe the namespaces or something else?

 

<ns1:SessionHeader soapenv:actor="http://schemas.xmlsoap.org/soap/actor/
next" soapenv:mustUnderstand="0" xmlns:ns1="urn:partner.soap.sforce.com" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><sessionId xsi:type="xsd:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">00DR00000007B0K%21ARcAQCypTASFnKDgtd.HE7mZosNWT6tNu_7g7tYJopQbqr7MLsn0wutY1ancvS_OT.U6Y6p4P_Z4cJ53G1ZajLEU3B9YgPdO</sessionId></ns1:SessionHeader>

 

 The session id is coming from Code B, here is the server url being passed onto code B:

https://cs2.salesforce.com/services/Soap/u/16.0/00DR00000007B0K

 

Here is snippet of code A:

public boolean validateSessionId(String sesID, String url, String username) {
	String sessionId = sesID;
	String serverURL = url;
	  
	URL uri = new URL(serverURL);
	        // binding
       SforceServiceLocator sserviceLocator = new SforceServiceLocator();
	SoapBindingStub sbinding = new SoapBindingStub();
	SessionHeader ssh = new SessionHeader();
	ssh.setSessionId(sessionId);
	String ns = sserviceLocator.getServiceName().getNamespaceURI();
	sbinding.setHeader(ns, "SessionHeader", ssh);
	sbinding._setProperty(SoapBindingStub.ENDPOINT_ADDRESS_PROPERTY, uri.toString());
        com.sforce.soap.partner.GetUserInfoResult userInfoResult = sbinding.getUserInfo();
        String userid = userInfoResult.getUserName();
        if (userid.equals(username))
        	return true;
}	     

 I can't use login on the binding since I don't have the password of the user account coming in.

 

Any thoughts?

 

Thanks

Praful 

SuperfellSuperfell

Newer API endpoints are much stricter on having the correct xml namespaces in the header. Your request looks suspect from that POV, can you post a more complete example (i.e. that includes the namespace decl's made in the envelope or header elements.)

PrafPraf

I included the header information in my original post and the code I posted is all there is. Is there something else you need? or tell me how to get it and I will reply back with the information?

 

Praful

SuperfellSuperfell

the snippet you posted refers to namespaces that must be declared further up the xml hierarchy. However you got that header snippet you should be able to get the entire soap message.

PrafPraf

How come a service that works on our production instance doesn't work on our sandboxes; I checked the API version of the partner WSDL on both instances and they are the same  on 19.0. Any ideas on that?

 

Praful

SuperfellSuperfell

Are you sending the sandbox requests to the correct URL?

PrafPraf

Yes, I checked that. 

I just tested the integrated application in the development environment and it works now. However, still fails if you try to invoke the application via SOAP UI or some other test client. weird.

PrafPraf

Thanks for the help Simon, will continue looking into this.