Access Client's File System from Rails application deployed at Heroku (for instance)

Hi,

Part of the Rails application, I want to let the client keep the
location string of a video file in the database at Heroku(My plan is to
deploy the application at Heroku). So, when the client wants to access
his or her file, the Rails application gets the location string from the
database and opens the matching local file from his or her computer. Is
this possible???

I appreciate your opinion/suggestion.

Regards,
Sagar

On Fri, Jan 25, 2013 at 8:44 PM, sagar p. [email protected] wrote:

Part of the Rails application, I want to let the client keep the
location string of a video file in the database at Heroku(My plan is to
deploy the application at Heroku). So, when the client wants to access
his or her file, the Rails application gets the location string from the
database and opens the matching local file from his or her computer. Is
this possible???

No. Just no.

On Fri, Jan 25, 2013 at 9:44 PM, sagar p. [email protected] wrote:

the Rails application gets the location string from
the database and opens the matching local file
from his or her computer. Is this possible???

To expand on Jordon’s “Just no”:

Heroku does not provide any local filesystem whatsoever. The only
files you can count on being there, are what your uploaded application
initially installs. The whole point of cloud-based automagically
scaling solutions like Heroku is that (assuming you spring for the
non-free plans) you get new resources spun up and down as needed.
Obviously they won’t have all the local files that your app has
created.

HOWEVER…

There is a common solution to this, namely cloud storage. Store the
files on Amazon S3 or some such, and it will be a bit more complex
than local storage but still quite feasible… and cheap so long as
you don’t store huge files or a huge number of them.

-Dave


Dave A., the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.

Thank you, Jordon and Dave.

I apologize if I am unclear. My question was to access client’s local
file system, not the Heroku’s. I wonder if your answer still sticks to
‘NO’.

S3 is not an option for me right now, because the application would
require user to save the video clip and get ready for another clip in a
matter of 20-30 seconds. Also, the application would be used in an area
where the internet speed is not that high (about 128 kbps). So, I want
to minimize the network traffic as much as possible.

Regards,
Sagar

Dave A. wrote in post #1093867:

On Fri, Jan 25, 2013 at 9:44 PM, sagar p. [email protected] wrote:

the Rails application gets the location string from
the database and opens the matching local file
from his or her computer. Is this possible???

To expand on Jordon’s “Just no”:

Heroku does not provide any local filesystem whatsoever. The only
files you can count on being there, are what your uploaded application
initially installs. The whole point of cloud-based automagically
scaling solutions like Heroku is that (assuming you spring for the
non-free plans) you get new resources spun up and down as needed.
Obviously they won’t have all the local files that your app has
created.

HOWEVER…

There is a common solution to this, namely cloud storage. Store the
files on Amazon S3 or some such, and it will be a bit more complex
than local storage but still quite feasible… and cheap so long as
you don’t store huge files or a huge number of them.

-Dave


Dave A., the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.

On Fri, Jan 25, 2013 at 9:24 PM, sagar p. [email protected] wrote:

I apologize if I am unclear. My question was to access client’s local
file system, not the Heroku’s. I wonder if your answer still sticks to
‘NO’.

This is exactly what my “no, just no” referred to. And not for any
more reason than it’s a huge security risk that you should not throw
you or your users into unless you absolutely know what you are doing
and they absolutely understand the risk they are taking.

On Fri, Jan 25, 2013 at 9:48 PM, Jordon B. [email protected]
wrote:

On Fri, Jan 25, 2013 at 9:24 PM, sagar p. [email protected] wrote:

I apologize if I am unclear. My question was to access client’s local
file system, not the Heroku’s. I wonder if your answer still sticks to
‘NO’.

This is exactly what my “no, just no” referred to. And not for any
more reason than it’s a huge security risk that you should not throw
you or your users into unless you absolutely know what you are doing
and they absolutely understand the risk they are taking.

To elaborate there are other reasons why the no applies, but this is
the only reason I care about.

Thank you both of you.

Regards,
Sagar

Jordon B. wrote in post #1093870:

On Fri, Jan 25, 2013 at 9:48 PM, Jordon B. [email protected]
wrote:

On Fri, Jan 25, 2013 at 9:24 PM, sagar p. [email protected] wrote:

I apologize if I am unclear. My question was to access client’s local
file system, not the Heroku’s. I wonder if your answer still sticks to
‘NO’.

This is exactly what my “no, just no” referred to. And not for any
more reason than it’s a huge security risk that you should not throw
you or your users into unless you absolutely know what you are doing
and they absolutely understand the risk they are taking.

To elaborate there are other reasons why the no applies, but this is
the only reason I care about.

Depending on what you’re trying to do there might be some java or flash
applet that will let you do that.
Theoretically you could just store the path and tell the applet to open
that file.

Your users would have to agree to install the applet and understand the
risks.

On Fri, Jan 25, 2013 at 7:50 PM, Jordon B. [email protected]
wrote:

and they absolutely understand the risk they are taking.
For more options, visit https://groups.google.com/groups/opt_out.


~ Jeremiah:9:23-24
Android 2D MMORPG: http://solrpg.com/,
http://www.youtube.com/user/revoltingx

On Fri, Jan 25, 2013 at 8:44 PM, sagar p. [email protected] wrote:

Part of the Rails application, I want to let the client keep the
location string of a video file in the database at Heroku(My plan is to
deploy the application at Heroku). So, when the client wants to access
his or her file, the Rails application gets the location string from the
database and opens the matching local file from his or her computer. Is
this possible???

You wish to keep the path of a file that exists on the user’s local
machine in your database in the cloud, and pass it back to the user?

I cannot begin to see how this would be possible unless your user had
a server running on their localhost that could serve up the file.

Trying to set a URL like file:///home/username/somefile cannot work
when you set it in a web page:

somefile

does not work when your web page is being served from elsewhere. Try
it. There are extremely good reasons for this.

I came across this FileSystem API in the DOM, that allows clients to
store and retrieve files from user’s Sandbox. I have not had a chance to
play with it yet, but seems like a bright light to me.

Regards,
Sagar

tamouse mailing lists wrote in post #1093872:

On Fri, Jan 25, 2013 at 8:44 PM, sagar p. [email protected] wrote:

Part of the Rails application, I want to let the client keep the
location string of a video file in the database at Heroku(My plan is to
deploy the application at Heroku). So, when the client wants to access
his or her file, the Rails application gets the location string from the
database and opens the matching local file from his or her computer. Is
this possible???

You wish to keep the path of a file that exists on the user’s local
machine in your database in the cloud, and pass it back to the user?

I cannot begin to see how this would be possible unless your user had
a server running on their localhost that could serve up the file.

Trying to set a URL like file:///home/username/somefile cannot work
when you set it in a web page:

somefile

does not work when your web page is being served from elsewhere. Try
it. There are extremely good reasons for this.