Add authorization via Session ID #29
Conversation
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/quickstart_oauth.htm Session ID Authorization - You can use a session ID instead of an OAuth 2.0 access token if you aren’t handling someone else’s password
lib/forcex/auth/session_id.ex
Outdated
| ] | ||
|
|
||
| "https://login.salesforce.com/services/Soap/u/#{starting_struct.api_version}" | ||
| |> HTTPoison.post!(envelope, headers) |
There was a problem hiding this comment.
@mmrobins it looks like we have different semantics for login between the 2 implementations of the Forcex.Auth behaviour. This one will raise if it encounters a problem whereas the other will return an error tuple (I think. I might have to dig in further). Regardless, it would likely be beneficial to have login and login!. It doesn't need to be part of this PR though.
There was a problem hiding this comment.
I dug in. They're all ! functions underneath, despite outward appear. Present-Jeff is shaming Past-Jeff.
You're good to go with this PR.
| server_url = extract_from_parameters(login_parameters, :serverUrl) | ||
| session_id = extract_from_parameters(login_parameters, :sessionId) | ||
| host = server_url |> URI.parse() |> Map.get(:host) | ||
| endpoint = "https://#{host}/" |
There was a problem hiding this comment.
Do we ever have to worry about other ports? What do the SFDC sandbox server urls look like?
There was a problem hiding this comment.
Not sure, but based on the format of the SOAP response I would expect if there were ports they would just come back in that extracted serverUrl tag and just work. I've got tests in the new commits I'm about to push, so if anyone hits any issue with sandbox urls (something I'll probably look into shortly instead of my 30 day trial I signed up for) it should be easy to debug and fix.
Step toward making these interactions mocked and testable
Wanted at least 1 test where auth header was already set for an example
Since the stubbed out Api module does all the parsing of the JSON that's returned the test doesn't exercise a ton, other than a url is called and kind of documents the format of the returned data.
So I can run `mix test.watch ---stale` and tests run automatically when I save files in my editor.
mmrobins
changed the title
|
Feeling better about these changes now that I've got some automated tests and manually tested both auth methods with a real salesforce org (signed up for a free trial for now to create the oauth stuff), and am using the library in my company's internal app on a WIP branch. Happy for any feedback on whatever before I merge though (ping @athal7) |
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/quickstart_oauth.htm
Session ID Authorization - You can use a session ID instead of an OAuth
2.0 access token if you aren’t handling someone else’s password
TODO
This works for my use case of session id auth, but still working on cleaning
all this up. Thought I'd put in a Work In Progress PR though to get any early
feedback.
Without tests for the oauth case I'm not sure if I broke that in some way. I'm
playing with figuring out a good way to test this by setting up an app oauth on
one of our test salesforce instances, and then actually writing tests with a
mocked out wrapper around the httpoison calls.
bulk api should be able to reuse the session id auth mechanism (especially
since I cargo culted most of the soap request from there), just needs a way to
set a different key for the auth header. Also, tests would be nice before I
change anyway, but we'll see.