username/password authentication with password expiry and account lock

[georges]

Anyone knows the best strategy to deal with situation where the SF instance enforces password expiration and account lock? It seems very impractical to deal with changing the password and ensure that no errand process will use the old password and lock the account by the time the updated password + token propagate thru.

Is there an easy way to obtain an OAuth and refresh token from the SF UI for a given account and use that instead of username/password?

[timrogers]

Could you just build a quick Ruby script to do the OAuth flow for you? I think that'll probably be easiest.

[adamthedeveloper]

I had our API user's password expire today. I reset the password through salesforce, updated my environment variables and published the new password to all of our hosts. Now, I am getting authentication errors when I try to authenticate! in a rails console. The client is showing the correct password in the attributes. So now I'm stuck. It feels like there is an additional step I probably need to take to get this working again, but I don't know what that would be.

Has anyone else experienced this? Sorry for hi-jacking this issue - it seems somewhat related. Basically, how the heck do we deal with password expiration and, once we understand what that is, what is the best practice for self-healing? Avoiding an outage would be great. I'm currently stuck/down without understanding what step I need to fulfill now that the password has been changed.

Looking for comments that might include a bit more hand-holding / code examples showing how some of you experts have solved it. @timrogers I think you are trying to help, but if you can include some documentation/examples of how to deal with this, that would be tremendous.

Thanks,

Adam

[adamthedeveloper]

@georges how did you eventually dig yourself out of this? Any help from anyone would be great. I’m blocked from using the API right now.

[georges]

Usually in this situation there are a couple of things that happen. If the service is configured with a wrong/old password, it will eventually lock the account because of too many retries. When this occurs the only way out is to shutdown any service/jobs that access SF api, which means downtime. Then you need to have the account unlocked by an admin. Then change the password for that account. Note that when a password reset/change occurs, there is a new security token that gets generated. SF usually sends it via email but you can also get it via the UI under Settings / Rest my security token. That token needs to be added at the end of the password for proper login. Reconfigure your service with new password+token and restart everything. You should be good to go. One way to go around this is to have a special policy created for the the account used by the API to never expire the password.

…

On Feb 3, 2018, at 6:58 AM, Adam Medeiros ***@***.***> wrote: @georges <https://github.com/georges> how did you eventually dig yourself out of this? Any help from anyone would be great. I’m blocked from using the API right now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#272 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAO681FCO0h6IvGGkZVu91n7bGLmZIUks5tRJAzgaJpZM4K7Lni>.

[sicktastic]

☝️ Yup. That's what I would do as well as @georges mentioned.

[adamthedeveloper]

@antwonlee @georges Thanks for getting back to me on this guys - I really appreciate it. I'll work on this and report back on the status.

[sicktastic]

Awesome explanation @georges . @adamthedeveloper please let us know if this worked or not.

[adamthedeveloper]

@antwonlee @georges I was able to get things going again by setting the security_token parameter to the new value on the clients. Concatenation of the password and the security token caused me to NOT be able to authenticate. After using the password alone (not concatenated with the security token) everything came to life. This is what worked for me.

So, explicitly setting the security token in the client options.

Fortunately, the api user was not blocked yet.