I have the following problem:
I have several image galleries which should only be visible to registered user.
The images are in one directory per gallery, each dir with a long, cryptic name.
But if you know the link, you can access the images without authentication.
Since I am using PHP on the server side, a simple approach would be "readfile" with .htaccess, but I do not want to pass hundreds of images through php.
So I tried a different approach: I used basic http authentication, with a dynamic generated .htpasswd file, containing access data for each loggedin user, which is resetted after 24 hours and after every logout of a user, so links on the images are broken after max. 24 h.
But I do not want the user to type in the cryptic, auto-generated username and password for this authentication, so I use urls like this:
http://username:password#path-to-image
That works perfectly in chrome, but in FF, when I want to include more than one image, the dialog to enter username and password appears for some of the subdirs of the protected one.
An example: I have the following dirs:
/gallery/one/
/gallery/two/
The protection is in an .htaccess file in /gallery/
And sometimes firefox only loads the images from /gallery/one/, sometimes only from /gallery/two/, sometimes none of these, sometimes both. If he doesnt load at least one of these, he asks to enter your username and password.
I cannot explain this behaviour, and I havent found a solution to make FF safely accept more than one url with username and password in it without asking.
Is there a solution for this problem, or do you have any other way to safely protect files on the server?
Thanks in advance.
PS: I have heard of mod-xsendfile, but it cannot be installed on my webhost.
Related
I have a public website with 1 page that is password protected. On this page are links to several pdf files and just some text. This page and the files are currently protected using .htaccess and .htpasswd files. When users try to access it a pop-up shows up asking for a log-in name and password.
It works, but I don't like how it looks. I'd like to have a page on the website where people can log in, with the same look as the other pages. (Like most websites have)
I have looked around for a while and found this:
Easy way to password-protect php page
After messing around with it for a bit I got it to work and I successfully password protected one page. The problem however are the pdf files on the page. I have no idea what to do with those.
So for my question, I'd like the following:
1) A nice looking page where people can log in.
2) 1 password protected webpage behind this log in.
3) Multiple password protected PDF files that are accessible through this webpage. (They can just open in the browser)
There is only 1 name with 1 password.
Any suggestions on how this can be achieved?
The problem is that on your 'secure' page, you can't provide a static link to the PDF file, else anyone who knows the link, has the PDF. This is security through obscurity, and is considered bad practice.
Two possibilities immediatelly come to mind to protect your PDF's:
Don't link to the PDF itself, but to a script that 'transfers' the PDF. The PDFs are in a directory that is not accessible (out of the root) for the web, but accessible for the script. The script reads from the PDF and writes to the client.
Link to the PDF itself, but configure the webserver to check for a valid session with your script. Users who use the direct link but are not logged in, receive an error. Bonus: configure the error page to go to the logon page. Using mod_auth_form could be the easiest way here.
I know that PDF files can be password protected, would you consider this as an option?
You would do this when you are creating the PDF file.
Okay, we have a subscription site up on our dedicated server. We feed content to paying members who access the site via our login page. Subscriptions are handled by a third-party biller who writes new member info to a database on our server. Member authentication is done using a MySQL database and not .htaccess/.htpassword. The reason for this was that much research showed that the .htaccess/.htpassword approach was insecure (transmission of user info via plain text) and that it offers no way for a user to log out. Thus the database authentication via MySQL. It all works great.
Except we have a problem in that the folders that contain members-only content need to be secured against anyone typing in the complete file path and file name to access the downloads content, thus bypassing our website.
So we went to the host and had a custom .htaccess file written. We had to do this in the interest of time, and they claimed to know about this sort of thing so we hired them to write the .htaccess file.
First iteration: It redirected every user login back to the index.php page instead of allowing access to the members area. Direct file access was blocked, however.
Second iteration: Member access to the member's area was restored and once again the content was vulnerable to direct download.
Third iteration: Successful access to member's area. Content access blocked to direct browser access. HOWEVER, ALL of the .jpg files that used to display with each of the download files in the member's area are now broken links. All of the thumbnails in the associated download file photo galleries are now broken links, preventing the viewing of the larger images they represent.
CONCLUSION: The host is backing out of the deal saying that what we want can not be done. To recap, what we want is:
Allow our registered members access to our member's area using our login page.
Preventing direct access to our content via browsers.
Allowing all of the .jpg images to display with the download files and in the thumbnail galleries.
They claim this can't be done, my suspicion is that they do not know how to do it. Certainly there are many subscription sites on the internet that use .htaccess files to secure their content.
ADDITIONAL INFO: We have an SSL certificate for this domain. Could that cause a problem? Shouldn't the .htaccess to protect our member's area content be in the member's area folder and not in the root (as it is now, and wouldn't that make the coding of the .htaccess file less complex?)?
I'm having a hard time believing that what we are asking to be done is not do-able.
Please advise. Any and all help will be severely appreciated.
Skip the .htaccess route. Store the file names for the 'member content' in MySQL. Then use .php to link to these for 'members only'. PHP would know only identifying information but not the actual file names. EG MySQL index #, storage date, member ID - all of these can be used to generate (and retrieve) a unique filename that you never expose.
I've done this before in Java using servlets in the 'src=' part of the img tag. I expect that PHP offers something comparable.
Actually this is about a cloud storage web app
A web app where user have their own private folder and i want they should have their own folders too .What could be the best way, to tell uploader that the file being uploaded has to be in specific folder in which user is in.
So what i thought is whenever a folder is created and opened a session which stores folder name is started and sent to uploader where Uploader that way uploads.
For eg $_SESSION['folder-name']='x'
$upload_dir= "/$_SESSION['username']/$_SESSION['folder-name']/"
Every user has specific private directory where they can upload files. So there is no chance that session can be manipulated to upload in wrong user directory.
Since now i see this way as the best way, is there any alternative i can get from stackoverflow community on this . if yes, please describe
Since your username is unique I suppose then I seems legit.
But lets see this scenario:
A user get's deleted and another one registers with the same username...
EDIT
It depends on the fs and many other factors. Eg is this going to be url accessible ?
An legit alternative could be:
Since the username as you set it seems to be unique then you could first md5 it (is quick) and then digest to hex if you want it shorter and url accessible. That will give you a good number of usernames that can be converted to folders.
Bad thing about this is that you can't find the user by the folder name. If you had that in mind
That's it.
So, I have a client requesting a solution to password protect files. He wants to basically have a solution similar to OpenDocMan. However he showed me something from another client that basically just password protects the file itself no user name. So he can upload files, put a password on that file, send links directly to that file and then when users click on a link they are prompted with the password and then the clients puts it in and the file is released. Anyone know of a solution that can do this exact requirement?
You can setup a basic validation page so that when a user visits a page they enter the document id (or it's encoded in the link) and you put up a simple form with a password field and a submit button.
If the password matches what is stored in the database for that document id. send that file to the user.
Keep the uploaded files outside the /web directory so you don't have to worry about people hacking the system by guessing filenames.
The files themselves won't have passwords on them, but the only way from the outside to get the file is to have the password.
If you don't have to have a unique password for every file, you can try apache's mod_auth. You drop a .htaccess & .htpasswd file in the directory you want to protected, and update the users/passwords in the .htpasswd file.
If you want something more dynamic, try mod_auth_mysql, so you have better control from your application.
I want my files to be secure in my web server. Only authenticated users to access those files should be able to access those files. I thought of storing files in database as "Long BLOB" but it supports only upto 2MB of data. The file size may exceed beyond 50MB. is there any other better way to secure the files? please help me.thanks in advance.
Don't store them in a database. Put them in your web directory and secure them using .htaccess.
If you want to authenticate via other means, then store the files in a directory that isn't web-accessible but is readable by the user php runs as.
Discussion
If you opt to keep high value downloadable content files directly on the filesystem, the best thing to do is to keep them outside of the webroot.
Then, your application will have to solve the problem of creating URLs (url encoding when necessary) for content (PDF's, Word Docs, Songs, etc..).
Generally, this can be achieved by using a query to retrieve the file path, then using the file path to send content to the user (with header() etc ..) when he or she clicks on an anchor (all of this without the user ever seeing the true, server side file path).
If you do not want user A sharing URLs for high value downloadable content to user B, then your application must somehow make the links exclusively tied to user A. What can be done? Where should I start?
Obviously, you want to make sure user A is logged in during a session before he or she can download a file. What is not so obvious is how to prevent a logged in user B from using a URL sent from user A (to user B) to download A's digital content.
Using $_SESSION to store the logged in user's ID (numerical, or string) and making that part of the eventual query (assuming content is tied to user purchases or something) will prevent a logged in user B from downloading things they have not purchased, but you will still incur the resource hit for processing the SQL empty set for items they have not purchased. This sounds like a good step two.
What about step one? Is there something that can prevent the need to do a query to begin with?
Well, let us see. In HTML forms, one might use a XSRF token in a hidden field to verify that a submitted form actually originated from the web server that receives the POST/GET request. One token is used for the entire form.
Given a page of user specific things to download (anchors), one could embed a single token (the same token, but different per page request) into each anchor's href attribute in the form of a query string parameter and store a copy of this token in $_SESSION.
Now, when a logged in user B attempts to use a logged in user A's shared URL, the whole thing fails because user A and user B have different sessions (or, no session at all), and thus different tokens. In other words, "My link is the same as yours, but different." Anchors would be tied to the session, not just to the page, user, or content.
With that system in place, PHP can determine if a request for content is valid without getting the database involved (by comparing the submitted token to the one in $_SESSION). What is more, a time limit can be established in $_SESSION to limit the duration/lifetime of a valid XSRF token. Just use the time() function and basic math. Sixty minutes might be an ideal token lifetime for an anchor in this situation. Have the user login again if the token for a clicked anchor has expired.
Summary
If you use files on a filesystem and store the paths in the database, make sure you do the following (at minimum), too.
Apply proper file permissions to your content directory (outside of webroot).
Use random names for uploaded files.
Check for duplicate file names before saving a file from an upload.
Only logged in users should be able to download high value content.
Have an effective $_SESSION system that deters session fixation.
Make URLs for high value downloadable content unique per page by using hashed XSRF tokens.
XSRF tokens cover more scenarios when they have a terminal life time.
Make SQL queries for user content based on the logged in user's ID, not the product exclusively.
Filter and validate all user input.
Use prepared statements with SQL queries.
A few options come to mind.
If you are using Apache you can use htaccess to password protect directories. (first googled link : http://www.javascriptkit.com/howto/htaccess3.shtml)
or
Store the files above the web server.
Create a script in php that will allow authorised users to access them.
If you want to do it Via FTP, and you are running cpanel you may be able to create new ftp accounts. check yourdomain.com/cpanel to determine if you have it installed.
Storing files in DB is very bad practice. Very good practice to store only information about file. Name, extension. Files save on server like $id.$ext. It will be a good architecture. And when user download file, he take file with name in DB.Sorry for my english.
The best way is to store the file reference in Database. The file itself will be stored in the server filesystem. The complexity of this is making sure there is reference integrity between the database file reference and the existing file in the server filesystem. Some database such as sql server 2008 have feature that maintain the integrity of the file references to the actual file itself.
Other than that securing the file itself in the server depends on the OS where permissions can be configured to the specific folder where the file reside.
If the files are purely static you could use read-only or WORM media to store the data files or indeed run the complete web server from a "LiveCD". It's certainly not suited to everyone's needs but for limited cases where the integrity of the data is paramount it works.
Downloadable files can be stored in htaccess protected folder/s. A script like the one below can be used to generate dynamic links for downloadable files.
for ex. Secure download links. http://codecanyon.net/item/secure-download-links/309295