I want to build a static website hosted by github which lets anyone make notes and saves them to a specific dropbox account. Then later users could access these files.
My only concern is that if the site is opensource then others can the token for the dropbox account and use it elsewhere.
Can I make it so my dropbox account only allows API calls from my website?Thanks in advance
No. This is fundamentally impossible. Whatever mechanism you used (e.g. the referer header) could just be faked by a malicious user.
Related
For visitors on my site to be able to use a 3rd party chat widget or be identified by Google Analytics, they must have access to whatever credentials are needed to call those 3rd party APIs from their front end. Does that mean they can easily grab those and programmatically send any requests to those services on my behalf?
Can those services use the domain the HTTP request originated from as a security measure? If I specify that the widget would be hosted on mywebsite.com, isn't it that anyone can fake an HTTP request that looks like it came from that origin?
Finally, is there any reliable security measure for such a scenario or do frontend-only widgets inherently give anyone access to the resource they use?
Any credentials specified on the front-end are available for users. They can use them any way they want (giving they know how), for example, any user can install GA or GTM on their site and use your id to push events to your analytics from their website.
I receive images for processing on my site and wanna omit uploading to local server and further adding to Dropbox folder from it by implementing direct upload to Dropbox from web browser.
Dropbox API is pretty simple, but has one problem - I need to expose API key to end user, and that key allows to download all pics from my account.
Then if I use Dropbox API - one user can download images uploaded by others, and it's not acceptable scenario.
Is there any way to bypass limitation with exposing full access API key to website end users?
Unfortunately, no, in order to upload directly to Dropbox via the Dropbox API, the client needs the access token. Further, the Dropbox API doesn't offer an upload-only permission.
Fundamentally, clients can't keep secrets, so any access token that exists client-side (in this case, in the browser) can be extracted and abused.
Edit:
The Dropbox API now offers some new pieces of functionality that may be useful here:
A) The Dropbox API now offers "scopes", which you can use to configure an app or access token to only a limited set of functionality, such as the ability to write but not read files.
You can find more information about the release in our blog post here:
https://dropbox.tech/developers/now-available--scoped-apps-and-enhanced-permissions
B) The Dropbox API now offers the /2/files/get_temporary_upload_link endpoint, which can be used to get a URL that a client can POST to in order to upload to a Dropbox account without an access token:
https://www.dropbox.com/developers/documentation/http/documentation#files-get_temporary_upload_link
I'm looking for the correct, secure way to store credentials for a third party API in an Outlook add-in. This overview of the different storage options only says not to store credentials in Settings, but not where to put them, so I assumed the RoamingSettings would be okay. Then I ran into this page with information about RoamingSettings, where it says that is not the right location either.
The question then becomes: What is the right place? Should I build my own storage solution and store/encrypt the credentials in a file or cookie? That does not feel very secure either, since we are talking about what is basically a web app running in an Iframe.
I assume you cannot implement another authorization scheme (token based, cookies etc.) for your API and you are stuck with Basic Authentication and its issues. If you are using ASP.NET, with all the samples available it could be very easy to add another authentication scheme that is more adapted to web clients (such as Office web add-ins).
Having said that, for me your best option is to use HTML5 storage or cookie storage (if not implemented by browser) to store your credentials.
The fact that the app is iFramed is not really a big deal. Those storages (HTML5: sessionStorage/localStorage) rely on domains separation which means that the storage slots where you will put the credentials will not be be visible by other apps, even those living on the parent iFrame.
You may also consider the fact that you may serve the web add-ins and the apis from the same domain. They are both web applications!
You can do what Outlook itself does for its POP3/SMTP/IMAP4 passwords - use CredRead / CredWrite Windows API functions. The data can only be decrypted under the local Windows account used to encrypt the data, so it cannot be take to a different machine and decrypted.
I don't think you can access these functions from JavaScript. This is for an OWA addin, not the Outlook application, is it?
I have come across few chat application and the website which I don't know how these things work. can someone tell me how these application works in the website.
I have seen some website with a chat widget for helping the customer for respective to their business. On signing in these application, a script file is send to email, when it is pasted over the website. Automatically a widget is created. And this widget and the application is connected externally.
Sorry, if my question is not clear. I will give some links of application and website which give you some idea what I'm trying to ask.
Website
http://www.a1000yoga.com/
http://www.voyzek.com/contact-us/
Application
https://www.zopim.com/
https://my.livechatinc.com/
What you mean is called providing Web API,
Wikipedia's definition of Web API is :
A server-side web API is a programmatic interface consisting of one or
more publicly exposed endpoints to a defined request-response message
system, typically expressed in JSON or XML, which is exposed via the
web—most commonly by means of an HTTP-based web server. Mashups are
web applications which combine the use of multiple server-side web
APIs.
In brief, They implement their service in their servers, and let you access their services by HTTP requests.
You sign up in their website and they generate a API token(a random string maybe), then when you want use their services, you send them your requests with your API token as authentication or identifying mean, and they process your request throw their application and with your data on their servers, and send you respond.
For example when you use this messaging services(or Captchas, Ads networks, etc), they provide a piece of Javascript containing your API code, then when someone views your web page, the code will send request with your API token to API provider servers and they process data for you.
You can then access to your data through their website, another API, email or etc.
I'm building a JS client for a set of REST WebServices. The client will be delivered as an embeddable iframe, which should load JS scripts based on user options (license profile, user admin options, etc.)
I wonder what's the most effective and efficient pattern to do that.
At now I have a single "bootstrap" script, which includes the other scripts. I could create the bootstrap script code dynamically (server side), to make it load only the set of scripts required by the user configuration. Anyway those scripts would be publicly available, even if the services are not enabled for certain users... IMHO that's not a good solution.
On the other hand, how to control the access to static javascipt files on a public folder?
I want to avoid to serve javascript code though my code. It would be an expensive overload for the application!
Mmm... I'm a bit confused...
Giovanni
In general, if you wish to control access to a resource based on a business requirement (licenses, user profiles etc) you have no choice but to route all requests for that resource through your application.
However, since you are you are sending the files to the client there is no guarantee that anyone in possession of the scripts is currently authorized or authenticated (license may have expired, etc). As such, you cannot infer that a request to your web services is valid based on the fact that a consumer knows how to call your web service.
There should be very little to lose in making the scripts publicly accessible (since there should be nothing that you wish to kept secret in them). So, in answer to your question, I would suggest authenticating and authorizing any requests at the web service level and allowing the javascript files to be publicly accessible.