Web Hosting Talk







View Full Version : A registration script without mySQL. Is this possible?


jonathanbull
09-18-2004, 11:40 AM
Hi there,

I'm looking for a releatively secure regsistrations script that will do all the usual stuff. Logins, registration, email verification etc.

Do these exist without using a mySQL database. From what I've been looking at, they don't. Hopefully someone can prove me wrong!



Thanks in advance,
Jon.

Burhan
09-18-2004, 11:42 AM
Well you would need some sort of database to store the registration information. MySQL is the natural choice since its available on almost all webhosting providers.

kneuf
09-18-2004, 12:52 PM
There are some flat file dbs out there, that are supposed to 'mimic' mysql (the commands and such), but I've never gotten one to work for me. You might want to try Hotscripts (http://hotscripts.com), they might have something.

jvmombay
09-18-2004, 12:58 PM
store it in a text file, encrypt it and your done.

BTW still you will be better off with a real DB

barrywien
09-18-2004, 02:43 PM
Storing flat file is not secure, as anyone can open the files if they manage to find them. Storing them in a non web accessible directory could be the answer, but you would be better with SQL.

Have a look hotscripts.com, search for flatfile and you should find some examples of hot its acheived.

lwknet
09-19-2004, 03:22 AM
a mySQL DB is just an array of flat files

even in *nix the storage of password is in a flat file, but ppl will still say it is not secure without knowing the permission stuff

non web accessible storage is of no better than just flat files, whoever manages to break in your server, who can get to there

the truely secure mean of storage is by truely secure programming

xelav
09-20-2004, 03:46 AM
You can use DM functions for simple database. No requests, but it's simple way to store structurized data.

Web Style
09-21-2004, 07:14 AM
Hello!

Use Files in secure directory, or SQL Lite (included in new PHP versions), or DBF files (simple file-based database included in PHP too).

Carp
09-21-2004, 07:42 AM
Usually when you FTP to your account, you have to open the "htdocs" folder where your files are. just save all the flat files in that main folder (before you click htdocs) and no one will be able to view them.

Kar-aK
09-21-2004, 12:41 PM
If you really have to use flat files, then if you're using PHP I recommending doing the following:

<?php|skip
username1|password1
username2|password2
username3|password3

That way you wont have to mess around with encryption, and if someone tries to access the file directly PHP will just give them a parse error.

However, there are much better ways of doing it. Encryption is your best bet just in case php ever gets disabled for whatever reason...

Here's some quick code to use such a file:


$handle = fopen($datafile, 'r+');
$validuser = false;

while (!feof($handle)) {
$arr = explode('|', fgets($handle, 1024));

if ((trim($arr[0]) == $_POST['username']) && (trim($arr[1]) == $_POST['password'])) {
$validuser = true;
break;
}


- Kar

ferox
09-21-2004, 03:51 PM
If the flat db text files are stored in a directory which isn't accessible from Web, any encryption method will do. After all, if one has gotten in, there's nothing to protect.

samsonh
09-21-2004, 10:11 PM
You can try SQLite that came with the new version of PHP

lwknet
09-21-2004, 11:32 PM
Originally posted by ferox
If the flat db text files are stored in a directory which isn't accessible from Web, any encryption method will do. After all, if one has gotten in, there's nothing to protect.

this is exactly what i thk, try putting more attenttion in securing your whole server, coz i bet you won't

/home/it_is_me_here/public_html/sensitive_cc_info_unencrypted_version.txt

Saeven
09-22-2004, 02:06 AM
If the flat db text files are stored in a directory which isn't accessible from Web, any encryption method will do. After all, if one has gotten in, there's nothing to protect.

Except your wallet and left kidney when CISP's investigation hits you for a $50,000 fine for having stored credit card information in a poor manner. Careful what you store and how!

There's much more to it than that, in fact, most scripting languages can read files from across the server without problem (enter safe_mode in PHP and open_basedir etc).

mySQL is your best bet, it affords you extra password security, and it allows you to efficiently abstract the data so that client info is not associated to the CC info for example. It also has built-in crypt functions you can use if you don't want to learn the basic two-way encryption schemes (like AES-256, RIJNDAEL, etc).

Don't leave payment info unencrypted though, learn to use mcrypt or something, it's a 5 minute crash course and will make things much safer. I'd hate to be one of your clients and come across this post and then realize that my information and credentials are in some text file on your server. Next thing you know it's a shared server where the admin doesn't know how to jailshell, and my data is all over the net.

Much better if it's a 29fE93hfh/$@1@49Df93 that's my first name instead ;)

mySQL will also give you a scalability that a flatfile can't afford. Also consider search times. Looking through a flatfile is at least a linear process, because in order to retrieve a client record, at least each element must be read. Even if you implement some type of binary search, or tree builder, it would be O(n) + O(nlgn) which is still > O(n). A database query uses vector cross product, and can often retrieve a single record in logarithmic time, that's O(lgn) and that's good stuff.

Consider the difference on 100 records.
O(n) means 100 operations.
O(nlgn) means at most 664.38
O(lgn) is at most 6.64 operations.

The difference is clear.


Cheers and $.02 to consider.
Alex

jonathanbull
09-22-2004, 06:09 PM
Thank you very much for all your replies, I didn't expect such a response!

I've decided to go down the mysql route, as I'd like a reasonable amount of security. As you may have seen - I'm having a bit of trouble!

http://www.webhostingtalk.com/showthread.php?threadid=324074

If anybody could help, I'd be most grateful.

Thanks again.

chrisranjana
09-23-2004, 08:12 AM
Good decision to go down the Mysql way !