Box Node: OAuth2 + JWT "App" authentication

Core Development Feature Requests
1

Hi,

I've been playing with the Box Node a bit, and have found that the provided OAuth2 flow isn't suitable for what I'm trying to accomplish.

Effectively, I'd like to write a "bot" which interacts with the Box API; it needn't (and shouldn't) authenticate as a user. For this use-case, Box provides the OAuth2 with JWT flow.

Because I need this, I'm already implementing it, but whether that gets merged into the official Box Node is why I'm writing this post.

I propose the following:

  1. The box-credentials configuration UI allows the user to choose which auth flow they wish to use. The default will be OAuth2; the alternative can be called "OAuth2 with JWT" or simply "App".
  2. The box-credentials Node should consume the official Box SDK, as it streamlines both the OAuth2+JWT flow and the OAuth2 flow, as well as any needed API calls.
    1. For the existing OAuth2 flow, this would be some refactoring which will ultimately reduce the box-credentials Node's LoC.
    2. This will likely eliminate the request dependency from the node-red-node-box package.
  3. The box-credentials configuration UI, when OAuth2+JWT flow is chosen, should allow for pasting of a JSON "config file", which is provided by Box when configuring an app to use the OAuth2+JWT flow. Otherwise, it'll need to know about a handful of credentials (client key, client secret, private key, etc.)--we can supply text/password fields for each, as per usual.
  4. The box-in and box-out Nodes needn't know about what authentication scheme is in use.

Given that the necessarily credentials (as persisted by NR) are not the same between these flows (though there is some overlap), I wonder if creating a completely separate configuration Node (in addition to box-credentials) would make sense? The implementation would need to be careful not to persist any credentials that could end up unused if the user changes the auth flow type.

Currently, once the OAuth2 credentials are set, if the token expires (because it wasn't getting refreshed), the box-credentials UI does not allow the user to do anything about it. It is henceforth intractably broken. The configuration has to be manually deleted and re-created. This straddles the line between "bug" and "terrible user experience". Whatever side of the fence you're on, the OAuth2+JWT flow might also need the capability to retry authentication.

In the future, supporting the "developer token" auth scheme could be helpful as well.

cc @dceejay

2

All sounds reasonable. Any API that requires manual reauth makes for a terrible experience when you are building unattended applications.

Personally I'd try to use the existing config node and allow it to store the different possible types of credentials. That will reduce the chance of orphaning off config nodes with unused credentials in.

3

Sounds good, I'll go that route then.

4

I note that currently, the "download" Node (box) only retrieves the raw file in bytes. This may be useful for some purposes, but to do any sort of text processing, a user would need to then determine how to convert a .gdoc or .docx file to something readable.

As part of this effort, I need to enable the ability to retrieve "representations" of files; specifically, I need the text of any given document. Box supports these representations of files, as appropriate:

  • PDF
  • Thumbnail
  • Medium image
  • Large image
  • Extracted text

It seems natural to enhance the box Node to allow the user to choose from these (with the default being "raw" data, as it currently works).

5

There are two different event streams; the "user" stream, and the "enterprise" stream.

They are wildly different, and this breaks some assumptions that the Node makes about what an event object looks like. For example, depending on the event_type property, the box Node will change properties of the object, eventually arriving in the message payload.

I'm now of the mind that the Node is doing more harm than good by attempting to normalize the event objects. There are myriad event types in each stream (e.g., ITEM_UPLOAD in user vs. UPLOAD in enterprise), the event data is dissimilar. Furthermore, granularity is lost when attempting to normalize, as an "upload" looks like a "create" looks like a "rename" in the Node's output.

Of course, this would be a breaking change. OTOH, given the authentication expiration issues I noted, I can't imagine too many users are running this Node in production.

Interested in feedback from @dceejay or @knolleary on this? :smiley:

6

This solution would be great - was it ever implemented - and if so - would you consider sharing it?

7

Thanks - I think I'm at that same conclusion

8

I’m facing same difficulty with Box nodes, but manage work around and quite successful.

  1. Install and authorize Box Cli on your node red server. (forget about tokens expiration and reauthorizations needs!!!)
  2. use Exec node to run any Cli command
  3. use after Exec some Json, Splitter, Switch node to accomplish your targets.
  4. loop through flow logic what is needed.

I run successful statically/analytical tool for more than an year for my enterprise and even now doing custom project to get data/metadata/task/assignments/file copy/move and any thing what is in Box Cli api to enhance Box<>User experience and easy integrations.

I’m keep open for experience sharing. let me know if interesting in my ideas.