search

jwagner79 / DropboxZimlet

A Zimlet for Dropbox integration. Provides the ability to save an attachment in Zimbra to Dropbox and attach a link to a Dropbox file when composing a message.
7 stars 7 forks source link

Service provider's own AppSecret should not be seen by each Dropbox Zimlet users #9

Open bucchi opened 11 years ago

bucchi commented 11 years ago

I guess that in common use case, each service providers is assumed to have a unique AppKey/AppSecret for this zimlet and provide the functionality to their end users.

Am I right?

Then from "oauth" point of view, service provider's own AppSecret should not be seen by their end users. Otherwise the service provider's own AppKey/AppSecret could be used for some attacks.

But from my understanding, current implementation download AppSecret to each end users' browsers.

jwagner79 commented 11 years ago

You are correct. Generally, you want to keep your AppSecret, secret. So, a better implementation would be to get it from the server side or encode the keys as suggested here: https://github.com/dropbox/dropbox-js/issues/6.

Would you like to submit a fix? Or suggest a change?

bucchi commented 11 years ago

I do not have test environment right now in my PC. So I am sorry, I can not make quick pull request. But I can do quick suggestion, which could be some help if you need fix right now, I hope.

Here is my suggestion; I do not know anything about dropbox api actually. But how about changing signature method to HMAC-SHA1 and reusing oauth.jsp of com_zimbra_linkedin zimlet? From my understanding, this jsp genarates signature with consumer secret(AppSecret) for you in server side. So you can keep secret on server side, right? And maybe It would be better to make consumer key/secret configurable.

How do you think about that?

jwagner79 commented 11 years ago

@bucchi I'm not sure that will work. Dropbox is using oAuth 1.0.

I think the 2 options are 1) Change the JS requests to use Dropbox-JS; or implement the encoded key mechanism as they have done and continue to make client side requests.

or

2) Change all the requests to be done server side.

bucchi commented 11 years ago

I am talking about OAuth1.0a too. So do not worry about that.

I think there is one more option, which actually my previous comment mentioned about.

Consumer secret(App Secret) should be on the server side, that is what we are talking about here, right? When you use HMAC-SHA1, consumer secret is used only for signing some string. And only the result is sent to resource server, in this case dropbox service site. Consumer secret itself does not have to be sent.

That means following two things; 1) zimbraDropBox.js does not have to know consumer secret(AppSecret). 2) zimbraDropBox.js has to know only signed result with consumer secret(AppSecret).

So who does signing anyway? That is where oauth.jsp comes for. oauth.jsp receives a request from zimbraDropBox.js and do signing and send back the result to zimbraDropBox.js. And zimbraDropBox.js do something using the result as it is implemented right now.

That makes sense to you?

I am not sure if this option needs less work than using Dropbox-JS which I do not know anything about. But I am sure this option needs less work than changing all the requests to be done at server side.

adamc2c commented 11 years ago

i no this sounds like a stupid ? new to zimbra just loaded it on one of my vps's how do i retrieve the app key/secret?

rajjuo commented 11 years ago

You have to create Dropbox Chooser and Core(App Folder) apps by using link mentioned below to retrive ChooserAppKey, ZimbraAppKey and ZimbraAppSecret.

https://www.dropbox.com/developers/apps/create