Is it a bad idea to write a file with php for authentication?
An example:
A user submits a login form. If the credentials are invalid, the PHP writes a new file with the filename as the attempted username, and the contents would have a variable containing the number of attempts. Then that file would be included for the next login attempt, and if login attempts= 2 or whatever, display a reCaptcha.
Are there any obvious flaws with such a technique? I see most suggest using a database to store the login attempts and such, and I have no problem with doing it that way, but I was just curious.
A file is just another form of a database. If you implement this solution carefully, there is no real difference between implementing this via a database or via files.
The problem is the extra overhead of managing the sessions via files and writing all the code to do this properly.
In the end a database operates on files as well except for databases in memory.
Handling files yourself is not very efficient. Databases solve some complicated problems that you will face when writing/reading to files yourself like mentioned here database vs. flat files
Related
I am a .net developer and devolving an application for a company. For that I need to write a little php script to meet my needs.
My app need to check some information which randomly change almost every second from internet. I am thinking to make a php script so that I can give app the needed information. My idea is to use a simple text file instead of a mysql database (I am free to use a mysql db also). And then make two php pages. For example writer.php and reader.php
work of writer.php is very simple. This file will save the submitted data to the text file I want to use as db.
reader.php will read the text file and then show as simple text and on every read it will also empty the text file.This file will be read by my app.
work done.
Now the logical questions.
reader.php will be read by 40 clients in the same time. If there is
any conflicts?
If this method will be fast than mysql db?
If this method is more resource consuming than a mysql db?
You will have to lock the file for I/O for the time of writting (PHP flock() function). This may slow down things a bit when there will be more clients at same time, as when file will be locked by one user, everyone else would have to wait. The other problem that may appear when writting alot o data is that writting queue may become infinite when there would be many write requests.
MySQL seems to be better idea, as it caches both write and read requests, and it is implemented to avoid simultanous access conflicts.
I am used to use Java and Spring Framework. But not so long ago I started learning PHP , to get familiar with another kind of language.
I am trying to write a simple thing for drawing using html canvas, so more then 1 user can use that at the same time to draw.
In Java i would use a class variable in controller to store the picture draw by users. And every 1-2 seconds users send the request with the new data they have drawn, so i can add the changes to the global variable. and then send the changes to every user. When a new user enters, the server sends the whole picture to him.
So, my question is, how can i store an application global variable in PHP? like in this example with picture...
As i see, after finishing, the PHP halts and all the variables die with it, right? So is there any way to make a variable application global? So i can get access to it from different parts of application?
I can save it to text file before finishing the script. and every time new request happens, read it again from text file, make changes and then write back to text file... but it's so crazy... isn't there any way just like in Spring Framework and Java that i used before?
You need a form of persistent storage. By persistent, I mean storage that is not based on an individual user's session like the $GLOBALS array is. PHP Sessions are useful for storage for a single user, but one user cannot access the session data of another user.
Persistent storage can be achieved a few ways. Some options: checking a row in a database table or storing a value in a file like you mentioned.
Database storage
Check out php's mysqli_query() for more information on doing this via a database. This will require knowledge of MySQL syntax.
File storage
Check out php's file_get_contents() and file_put_contents() for examples on how to easily interact with retrieving data from files and setting data in files.
As DevZer0 answered - you want to use sessions. More information about session you will find in the php manual: http://www.php.net/manual/en/intro.session.php
I am trying to give user an option to register into the system and want to link the page to another php file say detail.php page with all the database variable remain active in that file. Please anyone can help me out..??
Other alternatives are cookies, (encrypted) POST parameters sent to that page or if you are using include statement to include the contents of that file in the current page, you may as well define your variables just before include and those can be used in the included file.
P.S.: Use of sessions is recommended; though its not clear from your question, why you dont intend to use sessions.
Any options you may have rely on the client sending some form of way of identifying the initial user.
You basically have 3 options:
Keep resending all of the data you need to complete the registration to every page via a form (i.e. as either GET or POST data).
Storing the data in a COOKIE and sending that with each request.
Storing the data serverside and using the session (and PHP session COOKIE)
Personally, I'd recommend sticking with using the session as it limits the amount of data being sent between requests. The only reason I can think of not to do this is if you multiple application servers and no shared storage for your sessions (i.e. memcache or database)
If you want to elaborate on your OP and explain why you don't want to use sessions, I'd be happy to give you a more indepth answer.
I'm currently trying to create a CMS using PHP, purely in the interest of education. I want the administrators to be able to create content, which will be parsed and saved on the server storage in pure HTML form to avoid the overhead that executing PHP script would incur. Unfortunately, I could only think of a few ways of doing so:
Setting write permission on every directory where the CMS should want to write a file. This sounds like quite a bad idea.
Setting write permissions on a single cached directory. A PHP script could then include or fopen/fread/echo the content from a file in the cached directory at request-time. This could perhaps be carried out in a Mediawiki-esque fashion: something like index.php?page=xyz could read and echo content from cached/xyz.html at runtime. However, I'll need to ensure the sanity of $_GET['page'] to prevent nasty variations like index.php?page=http://www.bad-site.org/malicious-script.js.
I'm personally not too thrilled by the second idea, but the first one sounds very insecure. Could someone please suggest a good way of getting this done?
EDIT: I'm not in the favour of fetching data from the database. The only time I would want to fetch data from the database would be when the content is cached. Secondly, I do not have access to memcached or any PHP accelerator.
Since you're building a CMS, you'll have to accept that if the user wants to do evil things to visitors, they very likely can. That's true regardless of where you store your content.
If the public site is all static content, there's nothing wrong with letting the CMS write the files directly. However, you'll want to configure the web server to not execute anything in any directory writable by the CMS.
Even though you don't want to hit the database every time, you can set up a cache to minimize database reads. Zend_Cache works very nicely for this, and can be used quite effectively as a stand-alone component.
You should put your pages in a database and retrieve them using parameterized SQL queries.
I'd go with the second option but modify it so the files are retrieved using mod_rewrite rather than a custom php function.
I'm thinking about storing list of passwords for users (eventually more info about them) of small-scale (max. 20 users) app in PHP file in directory like public_html_root/system/config/
<?php if($calledByApp !== true) die();
$pwds['username1'] = 'hispassword';
$pwds['username2'] = 'herpassword';
$pwds['username3'] = 'anotheroned';
?>
Now. hispassword is actually hashed version
$hashedpasword = sha1($password.sha1($salt));
This way, if file is included, it checks for $calledByApp, which is set upon starting from entry point - i.e. index.php in root, so we could say it's safe this way. If it's called directly from browser - it won't get served as text file, but rather as PHP file - and it will die also, since $calledByApp will return null or false.
Also, if another user is stored/deleted, the file gets rebuilt, so it reflects all users. And after including this file, we have all users in pretty array, so if we call
if (is_string($pwds[$sanitized_username])
&& ($pwds[$sanitized_username] === $sanitized_sha1_userpassword))
we'll do login.
My question is: Is this safe enough?
Clarification: DB for users seems to be a bit overkill - another table for max 20 users. Also, while this doesn't check if user is real, it won't do anything with DB - looks like added security too.
If for some reason mod_php has a hiccup it could result in httpd showing the uninterpreted file; store the script outside of the document root in order to fix this.
I would rather place that file outside of document root instead of relying on the PHP interpreter not failing for any reason.
No - this is a really bad idea.
By making your souce code files writeable you open a whole avenue for attacking your system.
Embedding data into source code is a messy practice - not least because it will not scale.
What happens if the file is locked for an update when a script tries to include it?
What happens when the connection to the browser is lost part way through writing the file?
If you're quite sure that you'll only ever have a very small number of users and a low level of concurrency then abetter solution by far would be to have a seperate directory, with all http access denied, containing one file per user, named with the username (or a hash of it if you prefer) containing the hashed password.
C.
It's always safer to store the encrypted passwords in a database.
If you are using a database then I would store user data in there. If not then I would look to start using one.