Custom per folder user credentials

I have a a PHP project that requires an admin page that will allow the customer to create a folder that corresponds to a job number and assign a custom username/password for that folder. There will then be 开发者_运维问答another page their customers use to log into that folder and upload/download files. What's the best way to handle the authentication? My first thought was to put the username and password in a text file inside the folder and prevent the server from serving the page using .htaccess. I'm trying to avoid touching a database for the project as I want to keep it cheap and simple. Does anyone have any better suggestions on how to handle this? FYI, this isn't a high security application. I doubt the customer will even spring for an SSL certificate.

You can get SSL certificates for free at CAcert.

Apart from that, using .htaccess+.htpasswd is a reasonable option here.

> What's the best way to handle the
> authentication? My first thought was
> to put the username and password in a
> text file inside the folder and
> prevent the server from serving the
> page using .htaccess. I'm trying to
> avoid touching a database for the
> project as I want to keep it cheap and
> simple.

OpenID is the answer to (almost) all your problems:

• You do not have store username and password => BAD(storing passwords securily is very difficult concept).
• You don't have to touch any database, because OpenID handle authentications for you.
• openId has very friendly libraries(LightOpenID is very friendly) and is free(open-source).

http://www.codinghorror.com/blog/2008/05/openid-does-the-world-really-need-yet-another-username-and-password.html:

As we continue to work on the code that will eventually become stackoverflow, we belatedly realized that we'd be contributing to the glut of username and passwords on the web. I have fifty online logins, and I can't remember any of them! Adding that fifty-first set of stackoverflow.com credentials is unlikely to help matters.

I think you should be using opendID(Facebook Connect, etc) to do your authentication. I even created a little program that handles authentication a lot like stackoverflow.com does(with nice looking widget). You can demo this on my simple webhosting at http://westerveld.name/php-openid/. You can download the code(uses LightOpenID under the covers) at https://github.com/alfredwesterveld/php-openid.

> I'm trying to avoid touching a
> database for the project as I want to
> keep it cheap and simple.

I understand you would want to avoid touching database because if not done correctly it is going to make your code-base harder to grasp. But to scale using a database is a must and if you don't code around this concept when you have to switch(because system can't handle any longer) you will have a maintainability nightmare.

Also does a database help you with coding because it will abstract all the little details doing I/O(using database makes coding easier). Luckily you don't need to use a full-flexed database like MySQL/PostGRESQL because PHP(>=5) does compile/install SQLite for you and you can just use it:

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain.

To abstract database away from your code you should learn about PDO to connect to SQLite. This introduction will learn you how to do(Good read!) this correctly.

These parts are especially important:

• Connecting
• Prepared Statements to prevent SQL-injections.

Then when you want to change the implementation from SQLite to MySQL it will be as simple as replacing new PDO to use MySQL instead of SQLite.

> What's the best way to handle the
> authentication?

Let OpenID handle the authentication and use the returned OpenID urls(unique) for authorization. You could store this information inside your desired database easily.

> prevent the server from serving the
> page using .htaccess

.htaccess could be used to prevent users from accessing certain files. Even easier would be to put these files in a location outside of where files will be served to web-browsers if possible. Off course you will have to put them inside that location if you also want users to access/download that file, but then you need to perform authorization.

> I doubt the customer will even spring
> for an SSL certificate.

Password theft is something I for sure don't like at all. In the past when I wasn't aware of the security I used one password for all my sites(remembering more is hard).When Lifehacker got hacked I needed to change at least the passwords for important sites not to get hacked. Right now I am using the excellent Lastpass to store my passwords securly and I create an unique password for every site. If you don't use SSL then stealing information(passwords) could be as simple as installing blacksheep. But luckily when using OpenID(proper OpenID providers like Google, MyOpenID, Yahoo!) most of the times the authentication is done over SSL.