6

I use force-wsc to connect to the SOAP API with a username and password/security token in production. As a best practice, I rotate the password (and therefore the security token) on this server account periodically. However, changing the password basically breaks everything until I can get all my servers reconfigured, and therefore results in some downtime (even if it's just a minute).

I've considered creating another server account to switch between, but that would cost $1800 / year (or more with Premier Success) just for that, and then records would be inconsistently created or modified by one of 2 different accounts (just minor inconvenience).

How do most people rotate their production credentials when using force-wsc? Is there a better way besides taking the site down for maintenance?

6

A properly written force-wsc app (or any other SOAP-based application) won't immediately be affected by password change; this is because a session remains valid even if the username or password for the user changes. You should be caching the session ID instead of logging in every time you need to update a record. This would give you time to update the password in your server configuration.

Alternatively, consider ditching the SOAP login command and instead using OAuth login. The access tokens you get from logging in this way are compatible with the SOAP API (just call setSessionId on your connector to use the access token). You can use something like ScribeJava to log in using OAuth. Even better, if you get a Refresh Token, you can continually generate new access tokens even if the username or password changes. OAuth refresh tokens persist beyond user name and password changes, and only expire when configured in the Connected App (e.g. every 30 days), or when explicitly logged out by the API or revoked by the user/administrator.

| improve this answer | |
  • Good point that the session ID will still be valid for a while. Unfortunately, in my case, sometimes certain nodes become dormant for a while and the session ID may expire due to inactivity, causing my code to log in again with the username / password. I wish OAuth login with auto token refresh was built in to force-wsc, as that seems like the best solution - you just have to work a little more to get there. Even with OAuth, can you still end up in a scenario where your refresh token is expired? In that case, would you ever need to re-login with the full credentials? – jon_wu Feb 14 '18 at 6:21
  • 1
    @jon_wu Depends on your OAuth settings. For example, you can set the refresh token to require a fresh login every 30 days. Aside from that, the user or an administrator could still expire the token. Unfortunately, you will need to still handle the situation where it can expire, but it should not ordinarily happen as long as nobody intentionally logs it out, and it is set to never expire. Once expired, then yes, you need to log in with the full credentials again. – sfdcfox Feb 14 '18 at 6:35
  • Thanks for clarifying. So it sounds like you should be mostly good with OAuth, but if you required a fresh login every 30 days, there's always a slight chance that the window where you're rotating credentials happens to be at that 30 day interval, which would lead to downtime. However, this is avoidable first with a rolling deploy prior to rotating credentials, so that seems reasonable. – jon_wu Feb 14 '18 at 7:12
  • 1
    @jon_wu Again, only if the administrator limits it to 30 days. "Forever" is an option you can use, then you don't have to worry about that possibility. – sfdcfox Feb 14 '18 at 7:21

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.