Why a certificate?

[yaronf]

Hi! I'm trying to get the client running. Why do I need to create a self-signed cert (a client certificate, I assume) just to use SSL with Box?

[jheld]

I'm certainly not a ssl/tls expert, but if the connection is served over https (oauth requirement), then the browser will require a cert to verify url to destination, and then decrypt. Yes, it is localhost (makes it easier), but I wanted to make the experience secure.

If you'd rather let another service handle the creation of the cert, you can also check out https://letsencrypt.org/ . I have used it for a different project -- fairly easy to set up. I didn't know it existed before I started this project...so I could update the README.

As box uses oauth for authentication, this was the reasoning.

Feel free to weigh in.

[yaronf]

Well I happen to be a SSL/TLS expert (really). I also know how to get a cert from Let's Encrypt or create a self-signed one. I just didn't understand that you're setting up a server on my machine, and still don't understand why. I'll give it a try though.

[jheld]

@yaronf oh, that's great!

Yeah, I only mentioned let's encrypt in case you weren't familiar.

The reason I'm setting up a server is because oauth2 from box will send a request to the machine with the access and refresh tokens.

I've been looking for more elegant ways to shut down the webserver after this oauth dance, and while keeping diycrate_app still running. I just don't usually have a lot of time to spend on the project at once.

Let me know if you hit any setup errors...

Thanks for checking this out!

[yaronf]

@jheld thanks for the clarification!
I tried a self-signed cert, and Box didn't like it. See attached screenshot.

On the other hand, LE doesn't work for me because you need to be a real Web server to satisfy their authorization process (there are alternatives but they are more onerous) and I'm on a home laptop behind NAT. In general, if Box expects the client app to always have a routable IP, that's not going to work. My guess is, you can tweak the OAUTH "dance" to get a 301 Redirect instead of a new HTTP connection (thus remaining an HTTP client), but I'm not very familiar with OAUTH.

[jheld]

I'm looking into the JWT solution for box. It let's you save an rsa key to box and just do server to server auth, with no user dance. I'll let you know.

[jheld]

I'd like to outline a couple of the workflow bits here, just so we're on the same page.

Did you create an entry of the diycrate app for yourself in box? You will need to get your own client_id and secret. I don't believe you have to "publish" the app, but you will need to create a developer app. I see you have a client ID of your email, which I think means you put that in by hand on your machine, so you likely have not gone through the dev app console on box. If I had a way of safely storing my client_id and client_secret in the app, then I would, and this Box setup process would be easier. It's not that I don't trust you, but because the app is open source, I don't know if anyone might use it nefariously.

If indeed you have not gone through those steps, let me know, and I'll do my best to get you up and running if you'd like my help.

Additionally, the NAT issue shouldn't be a problem, and this is because the URL I put in my version of the box app creation is localhost. I imagine this is a pretty safe solution :) Box asks for your user/password and asks you to grant diycrate access to x,y,z permissions, and then sends back a redirect to the URL in the oauth callback I defined (localhost at port 8080).

[yaronf]

This all sounds like something I could do, but in general, way too complicated for people who just want to use a packaged application. Are you saying that you need some kind of developer ID registration with Box as a prerequisite for using their SDK?
If this is just for your own use and a few other brave souls, fine. But if you really want to open up the code for "real people" to use, I suggest that you go on their support forum and ask if this is the only way to create a client application.

[jheld]

@yaronf yeah, I was thinking the same thing. I'll contact them to see about more direct ways to use the SDK. It's really not a great system for hobby/personal use. Their SDK is open-source, so I'm surprised they haven't already put out better ways. Unfortunately the oauth keys are an issue. If I hear back, I'll update you, and probably make some edits to the README...which is woefully incomplete.

[jheld]

There is a RemoteOAuth2 client for the box sdk. I'm discussing usage with the devs over there to see how I can integrate that workflow for this app.

Hopefully we can get this solved and make it real easy!

[jheld]

Hey @yaronf I have some updates.

It seems the RemoteOAuth2 is the right way. There isn't much documentation for usage and they're still looking to make it easier to work with.

However, I do have a version of it working, and a server up and running in the cloud. This server stores the client id and secret information. I construct the Oauth object on the server on each payload, so it's not great...but seem to be good enough for now, since the server is only used for getting a couple of things. Once the client app gets the new access and refresh token, it doesn't need the server. I probably need to improve the refresh mechanism, but for right now you should be able to MVP an install.

Short order is please grab the release/0.2.10.3 branch and I imagine this should work. If you get a runtime error about the config file, try running it again.

The new command args to run with are:
--authenticate_url="https://45.55.237.251:8081/authenticate"
--authorization_url="https://45.55.237.251:8081/auth_url"
--token_url="https://45.55.237.251:8081/new_access"

I have the client app make a secret and store it in redis so that future logins to the server with an access_token don't just get it without being in the secret store. It still needs improvements, but it's a start.

Please let me know if you end up trying this version, and how well it works.

[yaronf]

Things are getting interesting on the new branch. I used a self-signed cert, so there were glitches. I completed auth to Box, and got a "bad cert" warning from Firefox. Added an exception and got a browser page with only "OK". But then I got a few Gnome notifies that files were downloaded into ~/box. Impressive!

[yaronf]

Synchronization works beautifully! However I have my password in ~/config/box.ini (where I would expect a refresh token or something of the sort). And of course I keep getting a warning for the self-signed cert.

[jheld]

I'm glad you got it effectively working!

I actually expect redis to be running on the local machine, which among other things, is where I store oauth access and refresh tokens. For sure it would be simpler to store those two tokens in the ini and update them as needed. Your password is in the ini...as in your box.com password? Thankfully you won't need that there. If you mean the client_id and client_secret...yes you'd be correct that the app currently requires those. It shouldn't, since the client app no longer uses them. If I were you, I'd set them to something like "Hello" on the command line and in a future update I'll remove that dependency entirely.

I'm still unsure if I can get rid of the client needing an https server. If I can, then that cert business can go away, and for the better, of course. It is a medium level priority in my head, but feel free to weigh since, especially since you're an early adopter. We can certainly tag a new issue for that to get researched & resolved.

Additionally, have you used redis before? I use it for the tokens as well as state information for the downloaded files, so that the next time the app loads it won't try to re-download the same file/version. This could get migrated to a traditional SQL-based solution, of course.

If you get redis working (for now at least), the firefox cert messages should mitigate some because we'll actually be holding onto the tokens. If the token needs to be refreshed, the app will delete the keys from redis and you'll have to restart the app.

[yaronf]

Attached my HOWTO, for Ubuntu users. Of course it should be updated as the command line params are changed. (Note that the file type should be changed to "md", this is a GH limitation0.
HOWTO-diycrate.txt

My personal direction for this is to try with the Box enterprise version, mycorp.box.com. Do you know if that's supported by the SDK?

[jheld]

I believe the JWT enterprise token is. I'd started researching it, but I wasn't sure how it might work for multiple users -- I'd love to try it out soon.

Additionally, in the meantime at least, you can use diycrate.xyz instead of that raw IP address; still use https and the same ports and paths.

And thank you for writing that up!

[jheld]

@yaronf I'm not sure the enterprise version is what we'd want. In this case, the users are only bound against that app -- so you'd have to manage those files completely separately.

So, unless I find an alternative, we're stuck the same tech on that branch.

[yaronf]

I'm confused. Of course my files on box.com are different from the flies I keep on mycorp.box.com (the Enterprise version that is managed by my company's IT team). So the local directory to be synched should be different. But we can still use the same technology to authenticate the user in both cases. My original question was whether the Box SDK even lets you access the enterprise account, because I didn't see anywhere where you can configure the basic authentication URL.

[jheld]

Oh, that makes more sense. I understand your use case better.

Yes, it should be able to work for your enterprise, but I may have to check with the box python devs about that, since I haven't seen examples about connecting to an existing enterprise/the mycorp domain. I'll report back after some research.

[yaronf]

@jheld, thank you!