8

I'm integrating a desktop app with SF using a c# component. I've created a login screen and can happily access all the fetures i want in my org from the application.

The problem i'm having is checking whether the sessionID (stored in a file after log on) is valid, so that if it is the user won't get prompted to login again the next time they use the c# component to interact with SF.

The only way i can see to do this from the docs is by using LoginResult which would require the user to add their username & password again... I'm sure im missing something, so very grateful for any suggestions!

12

As joshbirk mentioned in another answer, OAuth is the preferred mechanism for authenticating users. The refresh token gives you a persistent value you can save (securely - treat it like a password!) and re-use to obtain new access tokens (equivalent to session id).

Having said that, if you're using SOAP, you'll still need to be able to create your binding object from the session id, regardless of whether you get that session id from a file or the OAuth Refresh Flow...

You will need to store the endpoint URL (from loginResult.serverUrl) as well as the sessionId. Later, you can create the SforceService binding object from the session ID and URL thus:

binding = new SforceService();
binding.Timeout = 60000; // One minute timeout
binding.Url = endpoint;
binding.SessionHeaderValue = new SessionHeader();
binding.SessionHeaderValue.sessionId = sessionId;

Now to check that the sessionId is still valid, you can simply make any API call, catch the exception and deal with it as appropriate.

try {
    GetUserInfoResult result = binding.getUserInfo();
} catch (UnexpectedErrorFault uef) {
    if (uef.ExceptionCode == ExceptionCode.INVALID_SESSION_ID) {
        // Re-authenticate the user
    }
}
3
  • Worked a treat - thanks! stage 2 OAuth... – paul Aug 30 '12 at 8:15
  • If we're testing the connection, is there any issue w/ just calling binding.login(...,...) again? I figure if the session is still active, there is no difference in cost to calling login, since you'll get the same session info, but there may be some other reason not to do it. – HungryBeagle Jan 7 '16 at 17:49
  • You would have to store the username and password somewhere, which might be a security issue. The question mentions that they don't want the user to have to provide username/password again. – metadaddy Jan 7 '16 at 18:39
5

Not sure what your current flow to get the session var is, but you might consider using OAuth with a refresh token flow:

http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com

You could either append this to your existing login screen, or to add even more security use it conjuction with login.salesforce.com. With a refresh token, when the access token (which is interchangeable as a session ID) returns expired, you can use the refresh token to get a new access token without the user needing to log back in.

Then your application can clear out the refresh and access token when you want them to need to login.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.