I have not been working on this during tha last days, waiting for some feedback from Box as well, now I have an Update on this :
"Hi Alessandro, There isn't a good way to bypass this process, and not something that we support. I'd recommend going through the browser step once, and just maintain / renew your access/refresh tokens such that you won't have to access a browser to make API calls. Apologies if this causes any inconvenience. I'll close this case out, but let me know if there's anything else I may assist with. Regards, Audrey Box User Services" This is complicating our situation, let me try to get more information because this is a very bad news for our use case. Cheers 2015-04-09 13:11 GMT+01:00 Karl Wright <[email protected]>: > Ok, I've looked briefly at this. > > I have a reference as well. It might be good to compare and contrast: > > https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified > > But nevertheless, let me put down what I think the flow is: > > (1) You register ManifoldCF with Box and get back a client ID and client > secret. Those are permanent. > (2) The next step is to get an authorization token. This currently seems > to require interaction with a UI (at least, that's how it is described in > the oauth documentation you provided). The authorization token is valid > for only 30 seconds. > (3) From the authorization token, you can get talk to a Box API to get an > access token, which gives you access to the rest of the API. > > > Is this correct? > > If it is correct, then as I understand it, what we want is a ManifoldCF > setup like this: > > - The connection stores: client ID, client secret, user name, and user > password. These are all permanent parts of the configuration. > - The connector will need to be able to obtain an access token on demand, > given the above information, when it concludes that it doesn't have a valid > one already > - Each connector instance will need to manage its own access token. So if > there are 10 connections outstanding, there will be 10 independent access > tokens, each of which is obtained separately and expires separately. > That's the only way this connector is going to work properly across cluster > members etc. > - The process of obtaining the access token given all of the credentials > must be completely automated as part of the connector code. > > Since step (2) above seems to require UI interaction, which would make our > plan not work, we should figure out whether that's in fact the only way to > grant a user's permission. My guess is that it is not; I'd put much money > on there being a programmatic way to do this. Even if I am wrong about > that, with a little investigation of the UI interaction, I bet you can find > a URL that if you post the right information to, you will be able to figure > out what you need to post to obtain the authorization token. At the very > worst, you can use a technique similar to how the Web connector submits > forms to fake out the Box UI. I can certainly help you with that; the HTML > parser code is in common and is available for all connectors to use. > > Thoughts? > Karl > > > > > > On Thu, Apr 9, 2015 at 7:31 AM, Alessandro Benedetti < > [email protected]> > wrote: > > > Of course Karl! > > This is the problem : > > Developing a Repo connector similar to Dropbox ( Box connector) . > > Authentication in Box is based on OAuth2. > > In details after a process to grant access to your application you get 2 > > parameters for you Repository Connector : > > Access Token and Refresh Token [1] > > > > To instantiate a BoxAPIConnection you need a Client_id,Client_secret ( 2 > > not mutable) and an Access Token and a Refresh Token (2 mutable) . > > The access token expires in 1 hour, the Refresh Token can be used to get > a > > new Access Token, when this happens a new Access Token is produced ( > 1h), a > > new Refresh Token is created and the old Refresh Token invalidated. > > > > Assuming the BoxAPIConnection object is managing properly the > refreshment, > > the Job will work until the BoxAPIConnection is living. > > When a Job finishes ( or Manifold stop and restart) a new Job will start > > with the old configured Access Token and Refresh Token ( that are not > valid > > anymore ). > > > > Unfortunately we can not set for the connector the only 2 not mutable > > params, as it is required user interaction to produce them so we need to > > configure all the 4 values. > > We can consider the Access Token and the Refresh Token produced by a > human > > user or an external application and sent to ManifoldCF. > > Using the current approach ManifoldCF should be able to update the values > > he has to be consistent with the updated values in BoxAPIConnection. > > > > A bigger problem comes when both a RepoConnector and an Authority > Connector > > are in place , but for this other complicate scenario I will wait until I > > have a clear situation from Box itself regarding their approaches. > > > > [1] https://developers.box.com/oauth/ > > > > > > > > 2015-04-09 11:53 GMT+01:00 Karl Wright <[email protected]>: > > > > > Hi Alessandro, > > > > > > It would be great if you could describe the customer problem from a bit > > > higher level, to see if there's a better design we could come up with. > > > What you have described is quite difficult to do with MCF due to the > > > multi-threaded and highly-cached nature of it. > > > > > > Thanks, > > > Karl > > > > > > > > > On Thu, Apr 9, 2015 at 5:55 AM, Alessandro Benedetti < > > > [email protected]> > > > wrote: > > > > > > > Hi guys, > > > > I have one question : > > > > *ManifoldCF Version* : 1.8 > > > > > > > > Developing a custom Repository Connector I have the need of updating > > the > > > > Repository Connector config based on a Custom Listener of events of a > > > > custom Publisher . > > > > > > > > This listener will react to the publisher events during a Job > > execution ( > > > > i.e. can happen during the addSeeds or the processDocuments) . > > > > The listener will need to change the repository config accordingly > and > > > save > > > > them in the database. > > > > The main reason for this is that we need to store in the DB the > status > > of > > > > the publisher, because a new Job will need to use the updated Repo > > > > Connectors config ( changed by others jobs) . > > > > To simplify the problem let's assume we do not have concurrency > > problems > > > > right now. > > > > In the future we will need to implement a solution that will be > thread > > > > safe. > > > > > > > > Cheers > > > > > > > > > > > > -- > > > > -------------------------- > > > > > > > > Benedetti Alessandro > > > > Visiting card : http://about.me/alessandro_benedetti > > > > > > > > "Tyger, tyger burning bright > > > > In the forests of the night, > > > > What immortal hand or eye > > > > Could frame thy fearful symmetry?" > > > > > > > > William Blake - Songs of Experience -1794 England > > > > > > > > > > > > > > > -- > > -------------------------- > > > > Benedetti Alessandro > > Visiting card : http://about.me/alessandro_benedetti > > > > "Tyger, tyger burning bright > > In the forests of the night, > > What immortal hand or eye > > Could frame thy fearful symmetry?" > > > > William Blake - Songs of Experience -1794 England > > > -- -------------------------- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti "Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry?" William Blake - Songs of Experience -1794 England
