function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
michaelforcemichaelforce 

Identity Confirmation / S-control Conflict ??

I have been seeing some strange problems pop up all around our org, and they all seem to support a theory I have developed which goes like so:
 
If a user is logging in from an IP address that is NOT on the whitelist, they are asked to activate the computer.  Once the machine is activated, they can then log in and use the application.  The user, however, will not be able to correctly display / utilize s-controls which make use of the AJAX toolkit.  The soap messages are not accepted by the API and it seems that the error returned is that of 'invalid session ID'.
 
Several users have reported s-controls not working, and upon adding them to the whitelist they began to work again.  I imagine that this would be a problem experienced by many customers by now... has anyone seen problems?
DevAngelDevAngel
The activation link that you receive from the application stores a token in a cookie.  This token is the key to accessing the service from a machine that is not whitelisted.

An SControl, or any other API client doesn't know about cookies.  What this means is that the scontrol or other API client needs to login with username and password+token.

Now, if you are getting your session id from the service and are not executing a login, then it should work properly.  If not, then Houston, we have a bug.
michaelforcemichaelforce
The toolkit (as you know) automatically uses the session ID from the current session when embedded (e.g. in a homepage component).  But just to make sure, I had added the following code which did not fix the problem:
 
Code:
var SessionId='{!$Api.Session_ID}'; 
sforce.connection.sessionId=SessionId;

 
As you said, the s-control is ignorant to cookies... unless you tell it to search for and read the cookie.  Perhaps there is information within it that would help us as part of a workaround.  Although I would anticipate that such a workaround would also require modification of the toolkit.
 
If this is a bug of some sort, I would guess that the reason we have not noticed it until now is due to the fact that our whitelist was pre-populated with all IP ranges used in the previous 6 months.  Therefore, the problem is only encountered today when new users are added, or when old users log in from new places.
 
So, in other words, it may be a growing problem for many customers who have not yet noticed and/or diagnosed it.
 
I am currently in the office at headquarters so I cannot feasibly remove my current IP from the whitelist... when I get home I will remove my range from the list and see if any s-controls run.