I'm looking at replacing our current file-upload solution, a bespoke java application which transmits files and metadata using sftp, with a browser-based solution. My intention is to have finer-grained control over who can and cannot upload by tying the upload to an authenticated session in a web app. This will also enable me to collect reliable data about who uploaded what when, etc, in a straight-forward manner.
My concern is that we need to be able to support uploading huge files- think 100GB or more. As such, I don't think standard HTTP is appropriate- I don't trust it to be reliable, and I want to be able to provide user feedback such as progress bars.
The best idea I've come up with so far is an embedded applet which uses sftp to push the file, but I'd like to do this using only js or similar if at all possible.
There is project that want to enable resumable uploads: https://tus.io/.
Its client library provides progress bar and resume-on-interruption in the browser.
You can integrate the server part into your app, to manage authentication yourself, while benefiting from the resumability!
Here is a blog post https://tus.io/blog/2018/09/25/adoption.html in which they mention it being used by Cloudflare.
Related
I have a Discord bot project on GitHub which deploys automatically to Azure Web Apps. Since my project uses an API, it needs a token in a 'config.json' file. I want to share my source code, but I couldn't figure out how to make this happen without revealing sensitive data like my token.
Is there a way to not hard code it? This may be possible with a Virtual Machine but I couldn't make it work with the App Service plan.
Does any one have idea about the best way(implantation) to send Bulk Google Cloud Messaging on a Linux server. (Personally I like non-java implementation) Any help, link or suggession appreciated.
Edit
I didn't try any method for bulk messaging. I know there is a php implementation for GCM too, But I like to know what should I consider before go for an implementation. Like, How to handle failed messages, Is there any limitation on http requests goes to GCM server, etc.
Finally, I found the best answer for my own question. We can send a message to 1000 Google could message recipients using one http request. Sending bulk messaging Shouldn't be that much complicated. Any language or tool are capable of sending appropriate http request to the GCM server is enough.
GCM allows you to attach up to 1,000 recipients to a single message,
letting you easily contact large user bases quickly when appropriate,
while minimizing the work load on your server.
As shown by this example, it seems that the server-side code can even be written in C#. This question also confirms that this approach works. Other people seems to be able to setup standalone Java applications, as shown here.
If you have to setup a Linux server to send GCM push notifications, you can freely chose to use C# or Java at your own discretion.
For what concerns C/C++, however, things are a little more complicated. This question (PHP) shows that GCM notifications can be sent using CURL, so I suspect that a "C/C++" implementation using libCurl could be possible. However you'll have to tweak it yourself, given that it does not seem to be the "standard way" to use GCM.
If you are familiar with PHP than implement it in PHP. Since GCM uses only 2 GETs with HTTPS, you can easily implement it in any language, even batch processing with curl (i am using this for testing). You can find the calls here.
Note that you need a curl.exe which is capable of doing HTTPS. The link from Avio's answer shows you how to do that in PHP, stick to that and do not use C++.
When creating a site/script to be on the client end of a RESTful API, what tools are available to create a "workbench" to explore the API, examining headers and responses while working through the design? Preferably one(s) that allow you to enter a custom endpoint, and create sample requests to see the responses. I recall seeing one nice workbench before, but its name has escaped me.
Re-found the one I remembered: The Apigee Console is a great interface for playing around with an existing API or building your own.
Mashery's I/O Docs is an open source workbench that you can deploy yourself on a Node.js server with Redis for storage.
If you have the wadl file of the ReST Services, you can load it in SOAP UI and use it.
EditedAnother much simpler tool Rest Client
First there is TornadoWeb, it's async and non-blocking, and on the other side: there is Dojo. If I use tornado, how can I communicate with dojo?
And the other problem, if I use a WSGI solution like Flask, can I make a "notification" with them? Or dojo must have an "open connection" to speak with the server, which is not done using WSGI? mean; Apache or CherryPy will not work with Dojo?
And if WSGI can't speak with Dojo, what about using Atom or Feeds to program notifications under WSGI?
NB: the notification will be devided on two: notification about products for all users, and notification about specific users; it will use sessions...
And last question, what about WebSockets and HTML5? the server must be compatible to use this option with the browser?
I'm not sure why Dojo seems to be the problem in the communication.
Dojo provides you with AJAX wrappers which you can use for almost real-time notifications in a web app with little load by making an AJAX request each 1-5 seconds.
If the app will have a lot of users, frequent AJAX requests can cause too much overhead quickly. Fortunately, you don't have to use Dojo to communicate with the server. You could have a look at Socket.IO and, if you want to stick to Python on the server-side, gevent-socketio. It uses the best technology available in the web browser (WebSockets, Flash sockets, comet) to provide real-time communication.
There is also dojox.socket but I think it's less robust (and far less popular).
You should remember, however, that by using any kind of persistent connection (be it WebSockets, Socket.IO or dojox.socket) you need an asynchronous server able to maintain many simultaneous connections.
The solution you choose should depend on the web app itself and its user base.
In my quest for a suitable Cloud IDE, I came across SourceKit, a Chrome extension that lets you edit your Dropbox files using the Ace/Bespin syntax highlighter. It's great! Except I don't really use my dropbox public folder as my web server :/
So I looked into the source code and it's 100% javascript -- it uses the Dropbox API to send/receive files. The Dropbox API uses REST instead of FTP.
So I thought - what if I could communicate with my FTP server using REST, just like Dropbox does? Then I could just plug that into SourceKit and modify my FTP server's files from a browser tab!
But after considerable googling, I've determined it's either impossible or I'm using the wrong terminology. I can't be the first person to try to do this.
Anyone know if this is possible?
If you are the owner of the FTP Server, maybe you could implement a REST HTTP client which would, then, answer the REST calls from the client (which would be SourceKit), but for normal FTP access (which is a protocol itself, like HTTP), you can't do it via REST (REST is just HTTP), you would need to do it via FTP calls.
Because Chrome plugins are written in Javascript and only Javascript, and because FTP is impossible with Javascript (all the solutions the Google Search returns use a server-side script or a Java applet), it is all impossible.