SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 83
  1. #51
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What karl suggested won't work on 6 of the 10 servers I checked, at least not if we put the files in a non-web accessable directory, as alot of hosts don't allow you access to that part of the server.

    The encryption idea is nice, only thing is, we were trying to stick to having them be able to either:

    a) click on the link to the file and be able to view it in the browser if their browser supports that file type

    or

    b) right click, save as - on the file link and be able to download the file straight to their hard drive.

    Wouldn't this not be possible if we encrypted the files?

    There would have to be a php script to decrypt the files before being opened/viewed.

  2. #52
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The "encrypted file decrypted through php" method would work exactly the same as the fileview.php?id=32 display method discussed earlier. If you aren't comfortable or still have doubts about how viewfile.php?id=12 will work, create a quick demo with just one mime type and check it out for yourself.

    Separate issue. In order for these images to be secure, they will need to be transfered via SSL, else all this effort is in waste as the images could be snagged during transfer. Just a nugget to keep in mind.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  3. #53
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ahhhh, yess yess... I see. Never done it like that. Learn something new everyday

    Yea, we're mentioning to our customers that in order to take full advantage of all the security features, they must be using an SSL.


    Side note: what method of encryption/decryption would you suggest? From what I know, most types of encryption/decryption require it to be compiled into PHP. In that case, we can't use it. We don't want our customers having to do that.

  4. #54
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Beats me, that might be a sticker now that you mention it. http://www.php.net/manual/en/ref.mcrypt.php requires a separate library. Most php encryption functions are one way.

    Some interesting comments on that page, though.

    Did I mention, this will probably slow down the system? I don't really know, this is fairly foreign territory for me but I suspect it would take at least a few moments to decrypt a medium-sized file.

    All things considered, have you considered binary storage with MySQL?
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  5. #55
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Would doing that with the viewfile.php?id=45 kinda thing, work the same?

  6. #56
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  7. #57
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well i know how to do it :-p , i just wondered if it would work the same with the right-click,save as.

  8. #58
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What happens on the server side to produce the file is unimportant to the end user. As far as their client is concerned, they click a link (vf.php?id=45) and the client gets data sent to it. All viewfile.php?id=45 methodology will work the same way... from a flat file, from a database or from a tripwire triggered by a cat recently awoke by a mild electric shock.

    Draw yourself up a small example viewfile.php?id=45 and you will know how all these scenarios will work, regardless of how the data is fetched on the server side.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  9. #59
    SitePoint Wizard geiger's Avatar
    Join Date
    Jul 2001
    Posts
    2,459
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    samsm, we're depending on the customer's server. We can't determine what they have. In addition, as this is a professional product, it must be adaptable to many environments. MOST servers won't cut it

    I think we may have to either go for a temporary Linux-only solution, or else find another way - fast!

  10. #60
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey, I'm not going to argue about what you can't do, you are probably right. Good luck, an Apache-only version may help things along.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  11. #61
    SitePoint Wizard geiger's Avatar
    Join Date
    Jul 2001
    Posts
    2,459
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah. My last post was just from the last page. Didn't realize there was another. Anyway, maybe we can try encryption.

    Question, though. Couldn't someone just take the key from another copy of FT and use it to decode whatever they want? Seems very prone to breaking.

  12. #62
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You wouldn't be using one key... no file would have the same key as another. Keys would be stored in the database and god help you if you lose them.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  13. #63
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, i tried it. One thing. They can't just click on the link and it automatically opens up the file. Say its a .gif . They should be able to click on the link and it opens up the file. HOWEVER, if they want to download it, they can rightclick on the link and download it. but this way seems to only work for them to download it or click on the 'open' button of the download dialog

  14. #64
    SitePoint Wizard geiger's Avatar
    Join Date
    Jul 2001
    Posts
    2,459
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For clarification, we need to be able to view the files regularly, because if someone uploads an HTML page and respective images, etc, the account holder needs to be able to view that document. If they download it, the relative files will be lost.

  15. #65
    ********* Genius Mike's Avatar
    Join Date
    Apr 2001
    Location
    Canada
    Posts
    5,458
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Just curious, but the whole point of your software is to secure file, correct? So, why then are you only doing the securing aspect now, so close to the deadline, when its been in the works for so long?
    Mike
    It's not who I am underneath, but what I do that defines me.

  16. #66
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The whole point isn't to secure files. The whole point of the software is to provide companies with a means to present their clients with files to review.

    The administrator logs in and can create new accounts. Within those, projects. Finally, the administrator can upload local files to individual accounts.

    An account holder logs in using a provided username/password and can view all files uploaded into his projects.

  17. #67
    ********* Genius Mike's Avatar
    Join Date
    Apr 2001
    Location
    Canada
    Posts
    5,458
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Ah, ok

    I actually had no idea of the whole point of the software

    Thanks.
    Mike
    It's not who I am underneath, but what I do that defines me.

  18. #68
    SitePoint Wizard geiger's Avatar
    Join Date
    Jul 2001
    Posts
    2,459
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    http://www.filetrack.com

    Also, I have some input. Tell me if it can be bent in any usable way. Unix-only:

    htaccess denies all access to files. Gets file URL has it does now, with a PHP script (i.e. getfile.php?id=10). The script checks login and if correct, overwrites htaccess with one that allows viewing. Opens file. Rewrites with htaccess denying access.

    Disadvantages:
    Unix-only
    Files insecure for period when file is opened

    I know it's not fullproof, but I thought I'd spit this out there. Any help? Thanks.

  19. #69
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    131
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you want the files to be locked for normal downloading you only have two options (which work regardless of a .htaccess file):

    1. Store them outside the document root
    2. Store them in a database

    If you store them under document root, anyone could access them (but as long as the person doesn't know about your directory structure and you deliver the files via PHP chances are *very* low that someone will just guess the correct directory and filename...).

    I think that it's no problem storing the files under the document root because no one will just guess the correct directory and filename - if you go like "if it's stored under document root anyone could download it" I could also say "if it isn't, someone could hack the server or database and get them" - it's just a question of the level of available security.

    I don't think, that the files are important enough to justify all the fiddling even with on the fly encryption and such (because if the server takes ages to deliver the file, the customer won't be happy, too)...

    ...just think about what level of security fits your needs because there almost isn't *any* way to do this 100% secure (and if you want it to run on almost every platform/webserver/database combination chances are getting even worse...)
    include_once('./sig.inc.php');

  20. #70
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The only problem with storing them in a database is the fact that we're faced with the issue that we cant actually open and view the files without having to click on 'save' or 'open' on the download dialog box. Therefor, if a they uploaded an .html page and the images that go with it, they cant just open the page and view it fine. The can with the current situation, but the current situation is not secure at all.

  21. #71
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    131
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When you set the headers right and stream the file through PHP you should be able to do with it whatever you want (in detail: it should behave like any other file the server delivers).

    The download prompt should only appear if the browser doesn't know how to handle the file (which means that he doesn't know the doctype of the file).

    It seems that your problem is located there - check for setting the correct document type in your headers...
    include_once('./sig.inc.php');

  22. #72
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But your missing the point, lol.

    if they are stored in the database, you cant view an html file that uses other images that they uploaded as those images would be included in the database as well.

    it needs to be a solution that will work for windows/linux , iis/apache. One that deals with storing the images in a directory. not the db.

  23. #73
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    KillaByte is correct, and I don't think he is the one missing the point.

    Originally posted by samsm
    I don't really understand the problem. I've actually done something before almost exactly like what Karl is suggesting and file.php?id=45 (complete with session verification) would work the same as any other file... from displaying to saving. What am I missing?
    Originally posted by Karl
    You're not missing anything Sam, it does work that way as I've done it myself.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  24. #74
    Bah, I'll just hack it DoobyWho's Avatar
    Join Date
    Jul 2002
    Posts
    476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay. Scenario. Company gets hired by Client to design a website. Company uses our software to setup a project for the client to view website comps. Company uploads a .html file and images in the .html file are referenced to the current directory (ie. , image.gif, not /adsasd/image.gif).
    The company then has to upload the respective images for that page. If the client then logs in, they are presented with a list of files. Ranging from the .html file to all of the images. If they click on the .html file, it will grab it from the database and display it. But the .html page will not show the images because the images are in the database still. In order to view an image, they would have to click on the image.

  25. #75
    SitePoint Wizard geiger's Avatar
    Join Date
    Jul 2001
    Posts
    2,459
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's what we're going to do:

    If the database solution works for all platforms, etc, we're going to do it. If it allows HTML files to be viewed properly, that's how I want it. But if it's not possible, it's till our best option and we need to take it.

    Ryan, once you get an answer if you agree with me, please go ahead and make this a database upload. There's no other way without compromising massive usability. I never guaranteed such HTML functionality, anyway. I don't even know if people expected it.

    In the future, we may be able to develop a better way of doing things, or maybe an add-on for specific platforms. Anyway, lets go with this if we can. We have no time left.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •