Apex Code Development You need to sign in to do that
Don't have an account?
jhart single sign-on works for na3.salesforce.com orgs, but not for ssl.salesforce.com
Hello,
We enable single sign-on to our application using C# which follows the example given in this tech note.
It's been working great for most of our clients, however with one client we always get an INVALID_SESSION_ID error.
I've noticed that this customer is on https://ssl.salesforce.com, whereas most of our other customers are on the NA servers (https://na2.salesforce.com, https://na3.salesforce.com).
We are setting the "server" argument in our code (just like in the tech note), and I've verified that the "server" argument passed to the login page does match the client's server (ssl.salesforce.com)
Could this be the reason? Has anyone else had this problem? Is this a known issue?
Given that the code works for so many of our clients, and it's a copy of Salesforce's own tech note, I'm not sure what to do to troubleshoot.
We enable single sign-on to our application using C# which follows the example given in this tech note.
It's been working great for most of our clients, however with one client we always get an INVALID_SESSION_ID error.
I've noticed that this customer is on https://ssl.salesforce.com, whereas most of our other customers are on the NA servers (https://na2.salesforce.com, https://na3.salesforce.com).
We are setting the "server" argument in our code (just like in the tech note), and I've verified that the "server" argument passed to the login page does match the client's server (ssl.salesforce.com)
Could this be the reason? Has anyone else had this problem? Is this a known issue?
Given that the code works for so many of our clients, and it's a copy of Salesforce's own tech note, I'm not sure what to do to troubleshoot.
In the web applications for our custom web tabs, we likewise follow the guidance in Tech Note #18 for passing session information through the URL query string (using the &sfs and &sfu parameters). I have likewise observed that the setting "Lock sessions to the IP address from which they originated," when checked, appears to interfere with our web apps' ability to connect to Salesforce.com. It appears to be a necessary but not sufficient condition--sometimes the connection succeeds.
My questions:
1. Is the setting "Require secure connections (https)" (on the same page) relevant to this discussion?
2. I presume that the new Identity Confirmation that's being rolled out is not relevant, since jhart's post is from October. Correct?
3. What guidance can I give to a customer who is determined to enforce these security options?