You are not logged in.
Pages: 1
Hi ^^
I'm happy to see the option for " Filesharing via URL " like EyeOs 2.5 in OneEye
Keep the good work !
Thanks Chris
Last edited by Chris (2012-02-19 11:47:52)
Offline
Welcome, Chris...where did you see such an option? O_o
Offline
Welcome, Chris...where did you see such an option? O_o
Luca, that's available in eyeos 2.5 and we should definitely add this to oneye, too. I think it's -technically- not that a big problem. We just need to add an url parameter with a hash, that's on a table pointing to an existing file.
But we need to think of some additional things, too: Are there any security related problems? What extra functionality do we need? I could think of:
requesting a password
temporary sharing (e.g. sharing for half an hour only)
maximum download number (e.g. remove the sharing when the file's been downloaded)
server administrators should be able to disable this functionality (to prevent "download platforms")
Any more things for the lists?
Best regards,
Lars Knickrehm
The oneye project.
Offline
Oh, ok, because by reading "I'm happy to see the option" I thought that he had really seen it in oneye 0.8!
Yes, it would be a great feature!
I think that there is a structural threat in this mechanism: many users use Google Chrome or use other browsers but write URLs in the search bar instead of the URL bar (it does not make sense, but I know tens of people who do that). When search engines receives new URLs, they add it to their index. Of course, 99% of the users does not think about this problem, so they could think "ok, this is a secret URL, so the file is secure and only my customers will know it, even if I do not add a password". Wrong!
So I think that we should force users to set a password.
If you write the sharing engine, I can take care of the UI to manage this (a new program "eyeShareURL", called by an eyeFiles button an by files and folders context menus), but since I'm very busy this month, I will be able to do it only the next month.
It would be very cool if it were possible to share a whole folder too (something like, instead of downloading a single file, the user is shown an index page with links on all the files of the folder...there is plenty of ready-to-use PHP indexers...of course, we have to seriously think about security when we do this). But maybe we could implement this as a step #2 when simple file sharing will be stable enough. Just keep in mind that such a functionality could be added in the future while you code the sharing engine ;-)
Offline
I think that there is a structural threat in this mechanism: many users use Google Chrome or use other browsers but write URLs in the search bar instead of the URL bar (it does not make sense, but I know tens of people who do that). When search engines receives new URLs, they add it to their index. Of course, 99% of the users does not think about this problem, so they could think "ok, this is a secret URL, so the file is secure and only my customers will know it, even if I do not add a password". Wrong!
So I think that we should force users to set a password.
Forcing to set a password sounds sad to me. What about using the HTTP header "X-Robots-Tag" instead (see https://developers.google.com/webmaster … s_meta_tag ) ?
If you write the sharing engine, I can take care of the UI to manage this (a new program "eyeShareURL", called by an eyeFiles button an by files and folders context menus), but since I'm very busy this month, I will be able to do it only the next month.
That's really a quite good idea: There's already an application, called "eyeShare", that's just copying files and folders into a group. What about improving its UI to support both, group sharing and url sharing?!
It would be very cool if it were possible to share a whole folder too (something like, instead of downloading a single file, the user is shown an index page with links on all the files of the folder...there is plenty of ready-to-use PHP indexers...of course, we have to seriously think about security when we do this). But maybe we could implement this as a step #2 when simple file sharing will be stable enough. Just keep in mind that such a functionality could be added in the future while you code the sharing engine ;-)
It'd be even better if eyeVisor, eyeImages, eyePdf, ... can be used to view those documents. Then a simplified form of eyeFiles could be used for those folders. I'm going to think about how we could introduce this. Maybe using a special (and hidden) "sharing" user - or even a lot deeper from inside the applications / system...
Best regards,
Lars Knickrehm
The oneye project.
Offline
Forcing to set a password sounds sad to me. What about using the HTTP header "X-Robots-Tag" instead?
Honestly I didn't even know about that header. I definitely like your idea
That's really a quite good idea: There's already an application, called "eyeShare", that's just copying files and folders into a group. What about improving its UI to support both, group sharing and url sharing?!
Well...sadly eyeShare does not work at all when using the real VFS. So I would suggest writing a brand new application dedicated to URL sharing, working on both virtual and real VFS. Maybe I'll write the eyeShare support for real VFS sometimes in the future, but it's not gonna happen soon
It'd be even better if eyeVisor, eyeImages, eyePdf, ... can be used to view those documents. Then a simplified form of eyeFiles could be used for those folders. I'm going to think about how we could introduce this. Maybe using a special (and hidden) "sharing" user - or even a lot deeper from inside the applications / system...
I don't think that we need such a complex implementation. The majority of people will be using it to share single files, like PDF or Office files, which can be just downloaded and viewed with the device's default viewer. But that's just my opinion
Offline
Well...sadly eyeShare does not work at all when using the real VFS. So I would suggest writing a brand new application dedicated to URL sharing, working on both virtual and real VFS. Maybe I'll write the eyeShare support for real VFS sometimes in the future, but it's not gonna happen soon
Fixed
Best regards,
Lars Knickrehm
The oneye project.
Offline
Oh, ok, because by reading "I'm happy to see the option" I thought that he had really seen it in oneye 0.8!
Yes, it would be a great feature!
I think that there is a structural threat in this mechanism: many users use Google Chrome or use other browsers but write URLs in the search bar instead of the URL bar (it does not make sense, but I know tens of people who do that). When search engines receives new URLs, they add it to their index. Of course, 99% of the users does not think about this problem, so they could think "ok, this is a secret URL, so the file is secure and only my customers will know it, even if I do not add a password". Wrong!
So I think that we should force users to set a password.
If you write the sharing engine, I can take care of the UI to manage this (a new program "eyeShareURL", called by an eyeFiles button an by files and folders context menus), but since I'm very busy this month, I will be able to do it only the next month.
It would be very cool if it were possible to share a whole folder too (something like, instead of downloading a single file, the user is shown an index page with links on all the files of the folder...there is plenty of ready-to-use PHP indexers...of course, we have to seriously think about security when we do this). But maybe we could implement this as a step #2 when simple file sharing will be stable enough. Just keep in mind that such a functionality could be added in the future while you code the sharing engine ;-)
Quote this is a very good idea.
Offline
Pages: 1