I’d encourage people interested in how Pierre solved this to read his explanation blog:
> New post! OAuth 1.0A with @apachenifi using ExecuteScript and #Groovy on a > @twitterapi… https://t.co/T1dXFchIFE <https://t.co/T1dXFchIFE> > https://t.co/BbjBXAjJyt <https://t.co/BbjBXAjJyt> Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Apr 3, 2016, at 9:04 AM, Pierre Villard <[email protected]> > wrote: > > Thanks Matt and Jeremy, > > I needed to do OAuth v1.0 A which seems a bit more complex to what is > expected by Salesforce. However your answers gave me great inputs to deal > with this situation. > To be honest, in the end, I got the job done in a different way... found a > way that did not require OAuth. > > Thanks again, > Pierre > > > 2016-04-03 11:32 GMT+02:00 Jeremy Dyer <[email protected] > <mailto:[email protected]>>: > Pierre, > > I just use InvokeHTTP for handling OAuth logins. I usually prefer to place > all of the OAuth login logic in its own ProcessGroup so that it can be > referenced from several places in my workflow and keep that logic separate > from the rest of the functional logic. At this point you can either have the > HTTP POST body sent to this ProcessGroup as the content of the flowfile or > have that ProcessGroup load a file from some location that contains the login > HTTP request body. I have attached a sample workflow where I use this > approach for logging into Salesforce.com. This example simply returns the > access token to the calling workflow via the output port but to Matt's point > you could certainly put it in a DistributedMapCache entry. > > PS - Just to help make things more clear the "FetchFile" processor in this > example loads a file that contains Salesforce.com expected POST payload as > described > https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_username_password_oauth_flow.htm > > <https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_username_password_oauth_flow.htm> > > Thanks, > Jeremy Dyer > > On Sat, Apr 2, 2016 at 11:47 PM, Matt Burgess <[email protected] > <mailto:[email protected]>> wrote: > Pierre, > > I'm no OAuth expert but maybe you could have a flow that hits the OAuth > service for a token (scheduled for the same duration as the token lifetime), > then stores it in a DistributedMapCache, then your other flows can fetch the > token for the desired operations? Alternatively, if you are to provide a > callback for the OAuth service, you could point it at a HandleHttpRequest > endpoint for further processing. > > Andy LoPresto (my go-to guru for all things security, and recently-named > committer to Apache NiFi) can probably make better recommendations on this > (sorry in advance if I'm feeding you to the wolves ALP ;) > > Regards, > Matt > > On Fri, Apr 1, 2016 at 3:33 PM, Pierre Villard <[email protected] > <mailto:[email protected]>> wrote: > Hi guys, > > I'm working on a new flow and I'd need to use OAuth for some HTTP requests. > Is there something available for this? Or a recommended way to get the job > done with existing processors? > > Thanks! > Pierre > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
